-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aurélien,
On 3/30/15 10:21 AM, Aurélien Terrestris wrote: > Thanks Christopher, I believe this was working by the time of > Tomcat 4.. but not completely sure, it was a long time ago :) Even for Tomcat 4, that would surprise me. - -chris > 2015-03-30 16:14 GMT+02:00 Christopher Schultz > <ch...@christopherschultz.net>: Aurélien, > > On 3/30/15 4:24 AM, Aurélien Terrestris 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 > > This won't work well with Tomcat's authorization checks, since > they occur before the filter chain in invoked. > > -chris > >>>> 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: >>>>> >>>> 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 >>>>>> >>>>>> ----------------------------------------------------------------- - --- > >>>>>> - - >>>>>> >>>>>> > 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 >>>> >> >> --------------------------------------------------------------------- >> >> 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGXJ6AAoJEBzwKT+lPKRY+koP/iaTP1QqkqgesJkLiSsuJBq8 wAt9ftVDWHDn4+QteaM8ZCO6xOTr8igOBJn0aAXua69YX/5iHcIgZsxGBh272ZpF XzUU8cPP2dpzLwlM/SvhJfqYuIRyK/D6HVdF3/M8RGmc6uZSzNeSPnrvgp0ZB/dt zaiAIMlf9QZzqE+7g0OHAtq1XhBYYWyHSfJtqFr6uV6ifFwTTZqjHrQc77otQzNn CU6c5QreGuB13gSEAjs8elBJ29xih/rzkRuch5qigs0uI4zr/nj06Lh18Xv9CnBf l17SKyqvAc6RoNhMg7PEx7pJQKyVkcHobtsXcV0/08B0SZiEDc9dX95YraNBdZ+l EjRbkYAVsm8fTr6Vqna4rq6J9+uHZkbJ0Tauh4uqf5ApFK1iQmOR+E4WHn6lxloq MZOfkM4jNQVgpje1lGz+YfQ/F+H1tSDhpZDvkIBlQ3hDPXVBrUWuM2btEQfrpfIK auM1oFnc484NhKoePg1h4rIsW68sx8Q1sbs6GO5mlynNmah7eqFanvwalocjjmcc nlyy7CxjcwwWM+X/YmAYZoJEIJMpEr4oxkEU0mvDEtS8rwTfTWptBy7teRQUPkSe w4nKTDDgJdb54Fz3J4SPbhz4CmFvR2876VJi+oa07p+0jOJztn2iz+uZslrff/Dr eABxJW4+StWmQSiN4QuU =FTmZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
