Roel, On 10/29/15 6:32 AM, Roel Storms wrote: > On Oct 28, 2015 21:01, "Christopher Schultz" <ch...@christopherschultz.net> > wrote: >> On 10/28/15 12:34 PM, Mark Thomas wrote: >>> On 28/10/2015 13:01, Roel Storms wrote: >>>> Hello, >>>> >>>> >>>> I was looking into session management on Tomcat 8.0.29 and found this >>>> comment: >>>> >>>> In apache.catalina.connector.Request method doGetSession(bool) line >> 2886: >>>> >>>> * // Attempt to reuse session id if one was submitted in a >> cookie* >>>> *// Do not reuse the session id if it is from a URL, to prevent >>>> possible* >>>> * // phishing attacks* >>>> // Use the SSL session ID if one is present. >>>> >>>> Why do you put more trust in a session id from a *cookie* then from a >> *URL*? >>>> Is there an (invalid) assumption that cookies are hard to manipulate? >>> >>> It is based on the fact that cookies require more effort from an >>> attacker to control. >> >> Just to clarify, the "attacker" in this case isn't the user of the web >> application. Yes, any client can send any header (cookie) they want. But >> an attacker trying to trick someone else into sending a cookie is going >> to have a harder time than trying to get them to click on a link that >> has an embedded session identifier. >> >>> Creating the session with the client provided ID is required for some >>> features to operate correctly. >>> >>>> Additionally I was hoping to find some* design documentation on the >> session >>>> mechanism*. Has anyone constructed any diagram or created some other >> form >>>> of documentation useful for figuring out how sessions are created and >>>> maintained? >>> >>> Not that I am aware of. The relevant source code isn't that long. >>> Reading it is probably the quickest way. >> >> Roel, what are you looking for specifically? The servlet spec lays-out >> when sessions are created/destroyed, etc. Do you think Tomcat needs >> documentation in addition to that? >> >> -chris >> >> > I understand the difference. But still, isn't it possible to not allow it > for cookies. You mention some web applications depend on it. In what way?
There are some web applications that will break if you disable cookies on the browser. There are other applications that will break if cookies are not used on the server as the means of communicating the session id from the client to the server. This usually happens when programmers don't realize that every URL emitted back to the client needs to go through HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL. If you don't do these things, cookie-based session-tracking will be required. > I am still looking into it but a.t.m. I am drawing my own UML diagrams to > figure out how an incoming Http packet results in a Catalina.Request being > generated and where I can intercept in order for me to use a different > session management mechanism. Do you just want to change from cookie-based session-tracking to URL-based session-tracking? Because you can do that using web.xml and don't have to write any code. If you want to completely change the way Tomcat deals with sessions, you can write your own Manager implementation and wire it in using context.xml: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html Note that session-id management and session-storage are separated in Tomcat. I don't think you'll be able to meddle in the session-id management of Tomcat without significant work. On the other hand, if you want to put session data into memcached instead of in the JVM's heap, you can write your own Manager to do that and allow Tomcat to continue to manage the session-id management with the client. > Someone pointed out that I might be able to achieve what I want using > interceptors. Let's see what we can find. It's still not clear to me what you actually want to do, so I can't offer any advice. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
