Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2017-02-13

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:27 MegaMatt joined #openam
06:50 aldaris joined #openam
08:04 aldaris joined #openam
09:25 Guest38115 joined #openam
09:28 Guest38115 left #openam
09:51 aldaris joined #openam
10:32 aldaris joined #openam
11:55 MegaMatt joined #openam
12:00 KermitTheFragger joined #openam
12:28 aldaris joined #openam
13:05 MegaMatt joined #openam
13:09 MegaMatt joined #openam
13:20 aldaris joined #openam
13:57 jjpp hi.
13:58 jjpp aldaris: https://bugster.forgerock.org/jira/browse/OPENAM-8512 .. any pointers that i might think about to recreate the fix?
13:58 aldaris 0x123adfe ?
13:58 aldaris hi
13:58 aldaris :)
14:00 jjpp (i have a chain and module that does zero-auth in case of existing session. to replace session token to notify apps that there is something that has changed in session. module succeeds but pap is not started, because of LoginState.getSSOToken cannot find session by LoginState.sid..)
14:00 jjpp you have to give the memorydump that goes with that pointer as well. :)
14:01 aldaris no session mode will not help much with that
14:01 aldaris and this fix was made to 13.5.0 anyways, so you shouldn't have that fix..
14:02 jjpp well.. the fix/this issue felt relevant because of some familiar stacktrace somewhere around there. (possibly some other issu that said that this issue resolved it)
14:06 jjpp i have to go back and try to understand it. last theory was that the new session is not activated yet (it should be, though?) and therefore not in cts and therefore cts-fetch will fail. no idea if taht makes sense.
14:07 aldaris barely :)
14:07 aldaris by the time any PAP gets invoked, the session should be already activated
14:07 jjpp all the words look like one should know them but the sentence still does not make sense? :)
14:08 aldaris the session may not be persisted to CTS (since sessions are handled asynchronously), but the async read operation should happen after the async create (as long as both happens on the same server - which in case of oauth login should always be true)
14:10 aldaris also: as long as you stay on the same server, there is no point in looking up the session in CTS, since it should be also available in the memory..
14:17 jjpp hmyeah. this particular case has nothing to do with oauth. just a chain with one module that should check if it is session upgrade and succeed for the same user if it was. but obviosly there has to be more to it (it actually is a specific mode of a much larger module that has code to kill sessions and to other funny stuff. need to check what exactly in this case)
16:29 aldaris joined #openam
18:32 MegaMatt joined #openam
19:03 aldaris joined #openam
20:09 aldaris joined #openam
21:41 MegaMatt joined #openam

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary