%session.Data killed after redirect
Any ideas on why my %session.Data array would be wiped out after setting %response.Redirect in OnPreHTTP()?
Context: trying to implement a SSO patter for authorization code flow. I mention this because it's all I can really pinpoint as to what's changing. Typically a user logs in by providing their username/password and we validate in our database and set the %session.Data property with the user info. The only difference now is that we start at the SSO sign on page and are redirected back to our auth page where I'm calling our authentication server with the auth code provided to get an ID token. For now, I've simply hard coded the %session.Data to the user I want.
I have tested this and set a global right before the redirect to check the %session.Data and it's as expected (i.e. there's a user, IP adddress, and all the things we need to check that a user is 'logged in'. The redirect parameter is set as the last thing before the quit in the OnPreHttp() method and we are redirected to a page where the first the OnPreHttp() method does is checks the %session.Data. In my logic, if it's empty it redirects back to the authentication page (ours not the auth server).
I have made sure I'm not running into any kills for the %session variable nor can I see any of the reasons a %session might be terminated: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…
My guesses are:
1) The session is being terminated somewhere in the background that I can see or debug
2) The auth server's response is setting or clearing cookies, thus losing the session ID being stored on the browser
3) Magic and gremlins
Thanks for any thoughts you may have!
Comments
First of all you have to check if it's a different Web Applications, then the Cookie path has to be the same for both.
If not, it will mean two separate applications with a separate session.
@Dmitry Maslennikov
Thanks but it's most certainly the same web app (i.e. the name in the url hasn't changed "localhost/csp/theSameWebApp").
well, then I would check the %session.SessionId, is it the same or not?
I did not work much with sessions last time. And most of my experience with using %session.Data was in a project where we used %session.Preserve=1. But I can't recommend using this way, it may cause many other issues from my experience.
Thanks. We use them quite a bit and from what I can tell, yes the session ID is changing so I suppose I'm trying to target what even is happening that's restarting the session.
I could understand that it might get haywire after going back and forth from the auth server, however, I'm losing my session after I've done my business with the auth server and all I'm doing is continuing to talk to the Cache server as usual.
I'm sure my issue is probably super application specific, but I thought I'd see if others had any ideas.
just asking is there a loadbalancer involved when you connect to your application? if so enable stickysession on it so it always reconnects via the same web server as a different webserver means a new session when connecting to iris/cache
@Timo Lindenschmid
Thanks for that suggestion! There's isn't a load balancer. I'm running IRIS on localhost and auth server is hosted with Okta.
This issue ended up being the Session Cookie Scope. My application was set to 'Strict' and setting it to 'Lax' solved my problem. For now this is just fine to accept since that's the setup of our production server, but I do need to find some resources to understand why this mattered.