On 24/11/2015 10:12, Roel Storms wrote: > It's to implement a new session mechanism that guarantees integrity of the > requests sent in the session and also protect the session from attacks > based on stealing or replacing the session identifier. This is a thesis I'm > working on and this Tomcat valve should prove that migration from cookie > base session management to this new session management can go without large > modifications at client and server-side. That's why it is important to make > it transparent to the user/developer. Performance is already going to be an > issue in multiple places but I'll see what I can come up with. > > I am weighing of transparency, ease of migration, performance and security > all the time. Checking at the Apache httpd level will make it harder to > migrate to this new session management mechanism and has some other > disadvantages. In theory i could do this session management in a proxy but > this has it's own disadvantages. Session scope is an important aspect in > it's security and scope is harder to get right in a proxy or in the httpd > server since I want to limit scope to the web application context and maybe > allow explicit session sharing between web applications. As you can see I > still have a lot to do. If I need any more information I will not hesitate > to ask. Thanks for all the info!
What does this get you over and above using TLS (which is rapidly becoming a given due to HTTP/2) and configuring Tomcat to use the TLS session ID as the HTTP session identifier? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
