|Re: [jetty-users] Dynamic session cookie name|
I am just reporting back on my issue with having multiple sessions in the same browser while wanting to use cookie-based session tracking instead of URL-based (for reasons of security).
I looked into the proposed solutions and found both quite unattractive. Hacking into the Jetty internals is not my ambition and rewriting seems too hard to get right in all circumstances.
I opted for a different approach and would like to hear if this is a good fix for security risks that come with URL-based session tracking.
I am still using URL-based sessions at the Jetty/Servlet level but have extended that with a cookie on the browser side. The name of the cookie equals the session id and the value is a UUID (or just any random secret with sufficient entropy) that was generated by the server at session creation and stored in a session attribute. A matching cookie is now required to allow a request associated with a session to be handled.
This was quite simple to add since our application server implements an application model where a session request handling object is registered as a session attribute. Requests are then handled by fetching the handler and dispatching the request to it. So the check can be enforced at one single point.
I would think this raises session security to a level similar to cookie based tracking but am curious what other people think.
Thanks in advance for all comments.
On 12/09/2016 11:24 PM, Greg Wilkins wrote:
Back to the top