> 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 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
