-
Notifications
You must be signed in to change notification settings - Fork 0
/elmr/session always returns a new session ID #3
Comments
That's true. Perhaps a second key needs to be set, like the HTTP Session in Tomcat. Cookies are used to manage that; perhaps that's the way to do it. |
This is tricky though. In thinking this through HTTP sessions would have to be able to scale horizontally, right? If that's the case, then we would need to install a session manager for Tomcat that allowed for that (like this one). It has issues, and would take some work to get moving. But it's an idea. I'd like to discuss our options though before we work on this too much more. |
Another thought. Elmr is temporary for us. We will eventually use congnito with SAML. Could we take a shortcut here and make the session sticky? If so, we can develop a simple solution to this problem. |
We can identify the user with the environment variable |
- Fix for #3 will look for the `Shib_Session_ID` request attribute. This has to be set in the apache config as a JkEnvVar. Can be overridden by setting a system property or context parameter (see README). - Fix for #3 also adds a new method to SessionData interface that takes a pre-computed key for saving data to the session data store. - Add system property and context parameters to configure the number of minimum and maximum connections to the session data store (see README).
@argherna please consider the following curl commands:
Note that sessionKey changes between the first call to
/auth/elmr/session
and the last call. This does not seem desirable to me. If the user's Shibboleth session has not changed then why should we change the session key ID? Also this could be a potential DoS attack. This would allow a single user to spam elmr with requests which would eventually blow out the Redis cache.The text was updated successfully, but these errors were encountered: