On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris <aterrest...@gmail.com > wrote:
> > If you write a Valve (which would be Tomcat-specific, and not work > > under other servlet containers), you could change the way Tomcat reads > > session identifiers from the request (and use a request parameter > > instead of a path parameter). > > Maybe could you also have a look on Filters since they're made for > modifying the request before it reaches the servlet (or modifying the > response after it leaves the servlet) : > > http://www.oracle.com/technetwork/java/filters-137243.html > > Yes I know how filters work. However their within the lifecycle of the webapp. A filter can't associate a session with a request :( > 2015-03-30 9:57 GMT+02:00 Wesley Acheson <wesley.ache...@gmail.com>: > > On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Wesley, > >> > >> On 3/29/15 1:15 PM, Wesley Acheson wrote: > >> > A team I am working with use tomcat 7 as their web container. The > >> > application cannot use url session tracking due to compliance > >> > reasons. > >> > > >> > One of the requirements we are facing is that the application > >> > should work in an iframe on the safari web browser, which blocks > >> > all cookies. > >> > >> Do you mean that Safari has been configured to block all cookies? > >> Because Safari won't block cookies just because you are using an <iframe > >> >. > >> > > > > Should have said its a third party domain name. That can't change easily. > > Should have wrote Safari blocks all third party cookies. > > > > > >> > > > >> For this purpose I'd like to post some value around that acts as a > >> > session Id. However I'm not sure if this is possible? > >> > >> If you write a Valve (which would be Tomcat-specific, and not work > >> under other servlet containers), you could change the way Tomcat reads > >> session identifiers from the request (and use a request parameter > >> instead of a path parameter). > >> > > > > I understand that the solution at the moment would be container specific. > > > > > >> > >> Or you could handle session-management yourself and not use > >> servlet-spec-style session-tracking (which would be WAY more invasive > >> to your application). > >> > > > > In the longer term this is probably better. For the immediate term I just > > need the > > lease invasive approach for the application. > > > > > >> > >> > *I'm aware that this won't work for common paradigms such as > >> > POST-REDIRECT-GET.* > >> > > >> > Looking at CoyoteAdaptor.java seems to suggest that session Id can > >> > only be retrieved using SSL COOKIE and URL. > >> > > >> > COOKIE is out because of third party issues. URL is out because of > >> > compliance. SSL may be a possiblity but only if it doesn't involve > >> > custom client certificates. > >> > > >> > Is there any good place to hook in a post parameter for retrieving > >> > and reattaching the session? > >> > >> I've not done this before. CoyoteAdapter calls > >> request.setRequestedSessionId in a few places, and I don't believe > >> CoyoteAdapter can be overridden or replaced directly. > >> > >> If you had a Valve that ran before anything else, you might be able to > >> capture the request, read a request parameter, and then call > >> setRequestedSessionId yourself with that replacement value. > >> > > > > Thanks very much I'm going to read up on valves now. > > > >> > >> YMMV > >> > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v2 > >> Comment: GPGTools - http://gpgtools.org > >> > >> iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF > >> 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo > >> QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 > >> C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 > >> 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW > >> jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI > >> 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 > >> GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN > >> k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk > >> IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 > >> 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr > >> G5g/FyojfAtvlnhe7+r4 > >> =0axs > >> -----END PGP SIGNATURE----- > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
