You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Wesley Acheson <we...@gmail.com> on 2015/03/29 19:15:08 UTC
Post Session Id
Hi All,
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.
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?
*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?
Regards
Wesley
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Wesley Acheson wrote:
> On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris <aterrestris@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 :(
>
A bit of thinking out of the box, maybe futile but one never knows.
The basic reason why "it doesn't work" now, is because these cookies are somehow
third-party cookies. Of course I don't know your application, but isn't there some way in
which this can be changed, to make these into "first-party cookies" ?
There maybe you could use a servlet filter to catch/set the cookie headers, and if needed
proxy something to the third-party server involved ?
To elaborate : if the main application is sending third-party cookies to the browser, then
these are "Set-Cookie" headers in the responses, said cookies having a domain part that is
not the server of the application. A servlet filter could rewrite these cookie headers,
and change the domain part to be the main server. Then they would be accepted by the browser.
Similarly, since the cookies would then be re-sent to the main server by the browser as
"Cookie" headers, they could be caught by the same servlet filter in the requests, and
whatever needs to happen with them, done then. (Having the servlet filter recognise such
requests, and possibly proxying them to the third-party server).
Complicated, but maybe less so (and less intrusive) than changing the whole application logic.
Further along the same line of thought, one could put a front-end Apache httpd server in
front of Tomcat, and do all this kind of stuff there, where there are already numerous
standard tools to do such things as URL rewriting, Cookie rewriting, conditional proxying
etc., in a generally simpler way than under a Java servlet engine like Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris <aterrestris@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 <we...@gmail.com>:
> > On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
> > chris@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
>>>> <we...@gmail.com>:
>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>> chris@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Aurélien Terrestris <at...@gmail.com>.
Thanks Christopher, I believe this was working by the time of Tomcat
4.. but not completely sure, it was a long time ago :)
2015-03-30 16:14 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>> <we...@gmail.com>:
>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>> chris@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVGVpSAAoJEBzwKT+lPKRY1jkP/0Onuep4c7wOO1UeLB8zeuFc
> ZOWf7YXhGpzxufTLJAsBrxtZpM/2EOu1Ht1MXjEFaQiSCqnpUsK9m9SnCg98uajw
> terP6eKGiOO5cIg4+oR6mAdxsDYWNNg+Ksdk1ZUauKKxX3UmKWDNhCLazVUtqSJW
> qIocqskAYH3VIqhxLbtEyQIGnyy7KQFRFwSS/gQj2aUsklX85+6UNuVZzbGgo6MK
> q3VcEhOyUYuuvQB78+DP+D1iiYNP1NAyqRtjkBZYilb34LegQvU0jIunvKUzvFqJ
> w6GLeXqVscVV9wdD9RYf/iIt9K63k+f2xZ+82gNN9IcknNW5o0hMFa+tdHSnjzEk
> X4kSmrw/e5RBX1yXeD16kadrZfwXsgIXFj9b4ELPaT/Z28ED0vb7GEh3QGC0Q36J
> X5hAPlZo+G5iXJb7xk8G0QTle3lgWuzeUMYqbIZepUkpvpkjVPqk5w+SkuqLWfzt
> IoWfL1aIAv8EgA5vS+sQ6ADsT1yYRLzm/n3R2sGnE5Rk8uNDV8C5cqfC7489mUnh
> SFJrKhnmcW2Jc84Vq+I3ZjAkneN3uBS6lOrX/VuuV3BT4zTOS3Ak/v7yJZ4r22RN
> qCvceHciuAnNKkUb33jZYwY2eZBfzb3myyjx6guHXQgXZZbzVX7PESDenujrT2FO
> BoEwFR4BfjOxSrzyoa43
> =G7fj
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> <we...@gmail.com>:
>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>> chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVGVpSAAoJEBzwKT+lPKRY1jkP/0Onuep4c7wOO1UeLB8zeuFc
ZOWf7YXhGpzxufTLJAsBrxtZpM/2EOu1Ht1MXjEFaQiSCqnpUsK9m9SnCg98uajw
terP6eKGiOO5cIg4+oR6mAdxsDYWNNg+Ksdk1ZUauKKxX3UmKWDNhCLazVUtqSJW
qIocqskAYH3VIqhxLbtEyQIGnyy7KQFRFwSS/gQj2aUsklX85+6UNuVZzbGgo6MK
q3VcEhOyUYuuvQB78+DP+D1iiYNP1NAyqRtjkBZYilb34LegQvU0jIunvKUzvFqJ
w6GLeXqVscVV9wdD9RYf/iIt9K63k+f2xZ+82gNN9IcknNW5o0hMFa+tdHSnjzEk
X4kSmrw/e5RBX1yXeD16kadrZfwXsgIXFj9b4ELPaT/Z28ED0vb7GEh3QGC0Q36J
X5hAPlZo+G5iXJb7xk8G0QTle3lgWuzeUMYqbIZepUkpvpkjVPqk5w+SkuqLWfzt
IoWfL1aIAv8EgA5vS+sQ6ADsT1yYRLzm/n3R2sGnE5Rk8uNDV8C5cqfC7489mUnh
SFJrKhnmcW2Jc84Vq+I3ZjAkneN3uBS6lOrX/VuuV3BT4zTOS3Ak/v7yJZ4r22RN
qCvceHciuAnNKkUb33jZYwY2eZBfzb3myyjx6guHXQgXZZbzVX7PESDenujrT2FO
BoEwFR4BfjOxSrzyoa43
=G7fj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Aurélien Terrestris <at...@gmail.com>.
> 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 <we...@gmail.com>:
> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
On Wed, Apr 1, 2015 at 11:50 AM, Rainer Jung <ra...@kippdata.de>
wrote:
> Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
>
> Currently I'm trying to use <tracking-mode>SSL</tracking-mode> in web.xml
>> but just running some local tests it appears that there are a number of
>> problems when using the JK connector and using this mechanism.
>>
>> First issue: Even though the requests are going through AJP which
>> supports
>> the SSL context information propegation, It appears I need to add a second
>> connector to serve over https. This is because the logic in
>> ApplicationConnector.java
>>
>> for (Connector connector : connectors) {
>> if (Boolean.TRUE.equals(connector.getAttribute("SSLEnabled")))
>> {
>> supportedSessionTrackingModes.
>> add(SessionTrackingMode.SSL);
>> break;
>> }
>> }
>>
>> Looks like the AJP connector doesn't accept that attribute.
>>
>
> Something we could fix, but you found a workaround.
>
>
Yeah I'm not sure if that is still an issue in TC8. When I'm not trying to
get something working in deadlines I'll try to provide a bug report maybe a
patch but I'm not sure if its the validation logic thats wrong or if the
connector should instead should have that property.
>
> Second issue: This is the actual issue that blocks us.
>>
>> When going over mod_jk to a tomcat instance it appears that the request
>> attribute SSL_SESSION_ID isn't populated on the first few requests to the
>> server. However it is populated on subsequent requests.
>>
>> This is causing the following exception.
>>
>> java.lang.NullPointerException
>> at
>> org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(
>> CoyoteAdapter.java:985)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.postParseRequest(
>> CoyoteAdapter.java:765)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(
>> CoyoteAdapter.java:416)
>> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
>> process(AbstractProtocol.java:611)
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.
>> run(JIoEndpoint.java:314)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:617)
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>> TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Closing and repopening the browser causes the same issue to occur again.
>> Which means that I'm going to have to go back to posting the id, after
>> places where we don't control redirects back to our domain, I'm going to
>> have to issue a one time session lookup token to lookup the session Id.
>> This means sharing a data source with the Valve and the web applications.
>> (basically a string->string hashmap) Hopefully I can use JNDI or similar
>> for a local map if not its going to be needed to be backed by a database.
>>
>> So remaining questions are two: How to get the SSL_SESSION_ID populated
>> on
>> initial requests? Can I share some object in memory with tomcat as the
>> container(in a valve) and the web application?
>>
>
> I currently see no reason, why it shouldn't be populated right from the
> start. Could you please check
>
> - whether Apache always provides SSL_SESSION_ID:
>
> Set "SSLOptions +StdEnvVars" and add %{SSL_SESSION_ID}X to your access log
> (using CustomLog and a LogFormat).
>
What I did before is I added the ssl options to apache and did an ngrep on
port 8009 loopback interface, apache was not sending it over the wire. It
was sending other SSL parameters
Now this could be just some error in my configuration I don't have it here
to check. I used whatever apache was installed by default by apt-get in
mint. And I couldn't find a precompiled mod_jk.so so I ended up compiling
it.
>
> This will log the ssl session id with every request that is handled by
> Apache in the Apache access log. If the field does not contain an id, then
> mod_jk has no chance of forwarding it and we need to solve that part.
>
I'm not at the computer where I saw this behaviour and as above I'm not
sure if its my fault. When I am back at the computer unfortunately I've
other things to solve. (such as my hacked together session tracking).
It looks like I'm way off the beaten path with trying SSL session over
mod_jk so I'm not sure if a fix is all that usefull to anyone?
>
> - whether Tomcat sees the right IDs:
>
> You can add %{javax.servlet.request.ssl_session}r to the pattern of the
> AccessLogValve to add the ssl session id to your Tomcat access log.
>
> If you can see the ID for the problematic cases in the httpd access log
> but not in the Tomcat one, I'll do a little test here to reproduce.
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by Rainer Jung <ra...@kippdata.de>.
Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
> Currently I'm trying to use <tracking-mode>SSL</tracking-mode> in web.xml
> but just running some local tests it appears that there are a number of
> problems when using the JK connector and using this mechanism.
>
> First issue: Even though the requests are going through AJP which supports
> the SSL context information propegation, It appears I need to add a second
> connector to serve over https. This is because the logic in
> ApplicationConnector.java
>
> for (Connector connector : connectors) {
> if (Boolean.TRUE.equals(connector.getAttribute("SSLEnabled"))) {
> supportedSessionTrackingModes.add(SessionTrackingMode.SSL);
> break;
> }
> }
>
> Looks like the AJP connector doesn't accept that attribute.
Something we could fix, but you found a workaround.
> Second issue: This is the actual issue that blocks us.
>
> When going over mod_jk to a tomcat instance it appears that the request
> attribute SSL_SESSION_ID isn't populated on the first few requests to the
> server. However it is populated on subsequent requests.
>
> This is causing the following exception.
>
> java.lang.NullPointerException
> at
> org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(CoyoteAdapter.java:985)
> at
> org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:765)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:416)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> Closing and repopening the browser causes the same issue to occur again.
> Which means that I'm going to have to go back to posting the id, after
> places where we don't control redirects back to our domain, I'm going to
> have to issue a one time session lookup token to lookup the session Id.
> This means sharing a data source with the Valve and the web applications.
> (basically a string->string hashmap) Hopefully I can use JNDI or similar
> for a local map if not its going to be needed to be backed by a database.
>
> So remaining questions are two: How to get the SSL_SESSION_ID populated on
> initial requests? Can I share some object in memory with tomcat as the
> container(in a valve) and the web application?
I currently see no reason, why it shouldn't be populated right from the
start. Could you please check
- whether Apache always provides SSL_SESSION_ID:
Set "SSLOptions +StdEnvVars" and add %{SSL_SESSION_ID}X to your access
log (using CustomLog and a LogFormat).
This will log the ssl session id with every request that is handled by
Apache in the Apache access log. If the field does not contain an id,
then mod_jk has no chance of forwarding it and we need to solve that part.
- whether Tomcat sees the right IDs:
You can add %{javax.servlet.request.ssl_session}r to the pattern of the
AccessLogValve to add the ssl session id to your Tomcat access log.
If you can see the ID for the problematic cases in the httpd access log
but not in the Tomcat one, I'll do a little test here to reproduce.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
Guys,
Thanks for all your suggestions, they are good suggestions but I'm not
going to reply to them individually.
The Valve for setting requested session Id works correctly. However I
implemented it POST only which is causing problems the application we are
using has a number of redirects.
Reverse proxy from a subdomain has been discussed internally and rejected,
this is to do with our business use case and the nature of the client who
we are dealing with. Its not pratical for us to mandate that they buy an
SSL cert for every top level domain that contains our application.
Get requests with a session Id in the url are out due to compliance reasons.
The same logic for A records in DNS which we considered also.
Currently I'm trying to use <tracking-mode>SSL</tracking-mode> in web.xml
but just running some local tests it appears that there are a number of
problems when using the JK connector and using this mechanism.
First issue: Even though the requests are going through AJP which supports
the SSL context information propegation, It appears I need to add a second
connector to serve over https. This is because the logic in
ApplicationConnector.java
for (Connector connector : connectors) {
if (Boolean.TRUE.equals(connector.getAttribute("SSLEnabled"))) {
supportedSessionTrackingModes.add(SessionTrackingMode.SSL);
break;
}
}
Looks like the AJP connector doesn't accept that attribute.
Second issue: This is the actual issue that blocks us.
When going over mod_jk to a tomcat instance it appears that the request
attribute SSL_SESSION_ID isn't populated on the first few requests to the
server. However it is populated on subsequent requests.
This is causing the following exception.
java.lang.NullPointerException
at
org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(CoyoteAdapter.java:985)
at
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:765)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:416)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Closing and repopening the browser causes the same issue to occur again.
Which means that I'm going to have to go back to posting the id, after
places where we don't control redirects back to our domain, I'm going to
have to issue a one time session lookup token to lookup the session Id.
This means sharing a data source with the Valve and the web applications.
(basically a string->string hashmap) Hopefully I can use JNDI or similar
for a local map if not its going to be needed to be backed by a database.
So remaining questions are two: How to get the SSL_SESSION_ID populated on
initial requests? Can I share some object in memory with tomcat as the
container(in a valve) and the web application?
On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
> Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> André,
>>
>> On 3/30/15 6:07 PM, André Warnier wrote:
>>
>>> Christopher Schultz wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>
>>>> Jeffrey,
>>>>
>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>
>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>> Session Id
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>
>>>>>> Wesley,
>>>>>>
>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>> chris@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.
>>>>>>>>
>>>>>>> Okay, that explains it.
>>>>>>
>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>
>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>> really no difference from a security perspective of
>>>>>> any of these strategies.
>>>>>>
>>>>>> - -chris
>>>>>>
>>>>> I may be being a little naïve here, but would the sessionCookieDomain
>>>>> parameter of the <Context> element work for
>>>>> the OP here?
>>>>>
>>>> No, because the "domain" of the "page" is considered to be
>>>> separate from the application being used, here (in an <iframe>).
>>>> Setting the domain of the cookie to the page-domain would
>>>> probably result in the cookie being (possibly) ignored by the
>>>> browser (because it came from the wrong domain) or the cookie
>>>> wouldn't be sent to the application because the domain wouldn't
>>>> match.
>>>>
>>>> That does bring-up another point, though: could the page-domain
>>>> be used to proxy requests through to the application? If so, none
>>>> of this work might need to be done. The browser would request
>>>> https://host.com/app and host.com would proxy through to
>>>> https://otherhost.com/app. It's more configuration and
>>>> networking work, but it's less application work which may be a
>>>> win.
>>>>
>>>> Re-reading this thread from the beginning, I still have a doubt as
>>> to whether I understand the issue correctly. That is because, as
>>> far as I know, an <iframe> within a Windows, is its own Window
>>> object, with its own "baseURI" etc.. And from the server's point of
>>> view, it is in fact like a separate "browser window", from which
>>> requests originate and to which responses are being sent, and it is
>>> for all intents and purposes indistinguishable from just another
>>> separate Window or Tab that would be opened on the same workstation
>>> by the same or another browser. So under what circumstances can a
>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>> considered as a third-party cookie and blocked by a browser ? (And
>>> if it were, would that not be a browser bug ?)
>>>
>>
>> http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
>> problem/
>> http://stackoverflow.com/a/486569/276232
>>
>> Wesley, it looks like there are some hacks available that might solve
>> your problem.
>>
>> http://stackoverflow.com/a/4702110/276232
>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>
>> Unfortunately, it looks like these hacks are outdated and no longer
>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>> ..
>>
>> It looks like there might be some other possibilities, but I can't
>> verify them ATM.
>>
>>
> So I would consider this as a browser bug. But nevertheless, that's how
> they work and one has to live with this for now. So back to the drawing
> board.
> The question here is : do the browsers reject the cookie
> a) just because it is addressed to an <iframe> ?
> or
> b) because (while being addressed to an <iframe>) the "domain" part of
> that cookie is determined to be different from the one from which the main
> window content is coming ?
>
> If (b), then the easiest solution would be to make it so that it isn't so.
>
> Let's imagine that the first main page is seen by the browser as coming
> from "http://serverA.domainA.com", and that this contains an <iframe>
> loaded from "http://serverB.domainB.com". With the response going to the
> iframe, comes a session-id cookie, whose domain portion is also "
> serverB.domainB.com", and this is (dubiously in my view) determined to be
> unacceptable by the browser, because it differs from "serverA.domainA.com".
> So the browser ignores the cookie.
>
> That issue would be solved, if the content of the <iframe> appeared to the
> browser as also come from "serverA.domainA.com" (like the main window's
> content), wouldn't it ?
>
> If so, why not make the server "serverA.domainA.com" act as a reverse
> proxy for the server serverB.domainB.com, and load the <iframe> from
> serverA too ?
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Wesley Acheson wrote:
> Because if they are reverse proxying on a subdomain then the subdomain
> needs a ssl cert basically.
I am not very bright, so I am still struggling a bit to understand the architecture.
(And I'll stop whenever you tell me to.)
The reason for me to follow-up on this for now, is that I have some experience in terms of
trying to play the "man-in-the-middle" kind of thing, by modifying request/response
headers and/or URLs to try to make them fit into a scheme; and I know that it is not easy
and can easily lead to dead-ends, particularly when you have to deal with redirects
in-between (think Google ads, client-IP checking stuff, akamai etc..).
So basically, the simpler you can keep the scheme, the better.
In this case, I am imagining the following :
- multiple clients access multiple sites of the main entity, via HTTPS.
- the entity returns a "homepage" which contains an <iframe>, said <iframe> being in fact
your own Tomcat application, which requires sessions, and this is what is not working
correctly at the moment, because of the "third-party cookie" issues described previously.
- I previously suggested that to resolve this, it would be feasible to have the <iframe>
document itself appear to reside on the same site as the entity homepage, and this
homepage server then acting as a proxy to your own site.
To which your answer (if I understand correctly) is that, if the main sites need to proxy
to multiple sites of your application, this would require a cert for each of those
websites (yours).
So obviously (or not) there is a requirement that if they proxy to you, this proxy
connection also has to happen under HTTPS (which, technically, is a choice, not an
obligation. It could perfectly be so that the dialog between the user browser and the main
site is HTTPS, but the dialog between the main site and your application server is pure
HTTP (or AJP)). But let's say for now that it must be encrypted.
There are several ways in which this could be done, without requiring one cert for each of
your sites.
One way would be that the connections between the main site and your sites are simple
HTTP, but go through a pre-established SSH tunnel to your servers.
(or a VPN).
Another way would be that when the main sites proxy to your sites, they do it in such a
way that they address always the same site on your end (needing a single cert), but that
the URLs which they proxy are rewritten in such a way that they allow you, on your end, to
"redistribute" these requests to several of your sites. (*)
The main point is that the user browsers never need to see any of this. To them,
everything always comes from / goes to the same "main" website under HTTPS. Whatever
happens on that main website and beyond is none of their concern.
Even in the <iframe>, any URL or data (or cookie) that they will ever see, will always
refer to the main site.
It is a situation which is in fact very similar to a load-balancing scheme, where one
front-end HTTP server acts as a load-balancer for any number of back-end Tomcats.
And the logic and the software to do that already exist and work well.
(*) In other words :
- the clients access https://www1.domain1.org/URL
https://www2.domain2.com/URL
- the server at www1.domain1.org proxies this to
http(s)://yourfront-end.yourdomain.com/site1/original-URL
- the server at www2.domain2.com proxies this to
http(s)://yourfront-end.yourdomain.com/site2/original-URL
- your server yourfront-end.yourdomain.com proxies this further back to
either
- yourtomcat1.yourdomain.com/original-URL
or
- yourtomcat2.yourdomain.com/original-URL
(or whatever)
and the responses go back the opposite way.
The point being that the only server which (possibly) needs a cert is
yourfront-end.yourdomain.com.
And all the rest is standard Apache httpd and Tomcat configuration, no special Valves or
Filters required.
>
> On Tue, Mar 31, 2015 at 5:35 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Wesley Acheson wrote:
>>
>>> This is getting off topic. The website that surrounds our website is
>>> available under multiple domains. I.e. They white label their product.
>>>
>> Hi. If you do not want to pursue this, I cannot and do not want to force
>> you.
>> But on the base of the scarce info available : if they are the surrounding
>> site, and your application lives in the <iframe>, then all they have to do
>> is set up *their* server as the proxy to you, not so ?
>> And in that case, why would they need to get any more certs than they
>> already have ?
>>
>>
>>
>>> On Tue, Mar 31, 2015 at 4:52 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>
>>> Wesley Acheson wrote:
>>>> Andre that works perfectly fine but not for our use case.
>>>>> Ok, thanks for the confirmation. My logical world is back on track now.
>>>> Not to nitpick, but your previous post was the first one in which you
>>>> mentioned SSL as part of the equation, wasn't it ?
>>>>
>>>> If you still have a moment : in that previous post, you wrote "Its not
>>>> pratical for us to mandate that they buy an SSL cert for every top level
>>>> domain that contains our application."
>>>> Could you in a few words explain why that would be necessary ?
>>>> I guess that I still do not clearly see that use case. Maybe just having
>>>> a look at the initial page which you mention, could help ?
>>>>
>>>>
>>>> On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>>> Christopher Schultz wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>
>>>>>>> Hash: SHA256
>>>>>>>
>>>>>>> André,
>>>>>>>
>>>>>>> On 3/30/15 6:07 PM, André Warnier wrote:
>>>>>>>
>>>>>>> Christopher Schultz wrote:
>>>>>>>
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>>
>>>>>>>>> Jeffrey,
>>>>>>>>>
>>>>>>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>>>>>>
>>>>>>>>> -----Original Message----- From: Christopher Schultz [mailto:
>>>>>>>>> chris@
>>>>>>>>>
>>>>>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>>>>>>> Session Id
>>>>>>>>>>>
>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>>>>>
>>>>>>>>>>> Wesley,
>>>>>>>>>>>
>>>>>>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>>>>>>
>>>>>>>>>>>> chris@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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay, that explains it.
>>>>>>>>>>>>>
>>>>>>>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>>>>>>
>>>>>>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>>>>>>> really no difference from a security perspective of
>>>>>>>>>>> any of these strategies.
>>>>>>>>>>>
>>>>>>>>>>> - -chris
>>>>>>>>>>>
>>>>>>>>>>> I may be being a little naïve here, but would the
>>>>>>>>>>>
>>>>>>>>>> sessionCookieDomain
>>>>>>>>>> parameter of the <Context> element work for
>>>>>>>>>> the OP here?
>>>>>>>>>>
>>>>>>>>>> No, because the "domain" of the "page" is considered to be
>>>>>>>>>>
>>>>>>>>> separate from the application being used, here (in an <iframe>).
>>>>>>>>> Setting the domain of the cookie to the page-domain would
>>>>>>>>> probably result in the cookie being (possibly) ignored by the
>>>>>>>>> browser (because it came from the wrong domain) or the cookie
>>>>>>>>> wouldn't be sent to the application because the domain wouldn't
>>>>>>>>> match.
>>>>>>>>>
>>>>>>>>> That does bring-up another point, though: could the page-domain
>>>>>>>>> be used to proxy requests through to the application? If so, none
>>>>>>>>> of this work might need to be done. The browser would request
>>>>>>>>> https://host.com/app and host.com would proxy through to
>>>>>>>>> https://otherhost.com/app. It's more configuration and
>>>>>>>>> networking work, but it's less application work which may be a
>>>>>>>>> win.
>>>>>>>>>
>>>>>>>>> Re-reading this thread from the beginning, I still have a doubt as
>>>>>>>>>
>>>>>>>>> to whether I understand the issue correctly. That is because, as
>>>>>>>> far as I know, an <iframe> within a Windows, is its own Window
>>>>>>>> object, with its own "baseURI" etc.. And from the server's point of
>>>>>>>> view, it is in fact like a separate "browser window", from which
>>>>>>>> requests originate and to which responses are being sent, and it is
>>>>>>>> for all intents and purposes indistinguishable from just another
>>>>>>>> separate Window or Tab that would be opened on the same workstation
>>>>>>>> by the same or another browser. So under what circumstances can a
>>>>>>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>>>>>>> considered as a third-party cookie and blocked by a browser ? (And
>>>>>>>> if it were, would that not be a browser bug ?)
>>>>>>>>
>>>>>>>> http://www.mendoweb.be/blog/internet-explorer-safari-
>>>>>>>>
>>>>>>> third-party-cookie-
>>>>>>> problem/
>>>>>>> http://stackoverflow.com/a/486569/276232
>>>>>>>
>>>>>>> Wesley, it looks like there are some hacks available that might solve
>>>>>>> your problem.
>>>>>>>
>>>>>>> http://stackoverflow.com/a/4702110/276232
>>>>>>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>>>>>>
>>>>>>> Unfortunately, it looks like these hacks are outdated and no longer
>>>>>>> work: WebKit patched this "bug" so that iframe cookies are again
>>>>>>> ignored
>>>>>>> ..
>>>>>>>
>>>>>>> It looks like there might be some other possibilities, but I can't
>>>>>>> verify them ATM.
>>>>>>>
>>>>>>>
>>>>>>> So I would consider this as a browser bug. But nevertheless, that's
>>>>>>>
>>>>>> how
>>>>>> they work and one has to live with this for now. So back to the
>>>>>> drawing
>>>>>> board.
>>>>>> The question here is : do the browsers reject the cookie
>>>>>> a) just because it is addressed to an <iframe> ?
>>>>>> or
>>>>>> b) because (while being addressed to an <iframe>) the "domain" part of
>>>>>> that cookie is determined to be different from the one from which the
>>>>>> main
>>>>>> window content is coming ?
>>>>>>
>>>>>> If (b), then the easiest solution would be to make it so that it isn't
>>>>>> so..
>>>>>>
>>>>>> Let's imagine that the first main page is seen by the browser as coming
>>>>>> from "http://serverA.domainA.com", and that this contains an <iframe>
>>>>>> loaded from "http://serverB.domainB.com". With the response going to
>>>>>> the
>>>>>> iframe, comes a session-id cookie, whose domain portion is also "
>>>>>> serverB.domainB.com", and this is (dubiously in my view) determined to
>>>>>> be
>>>>>> unacceptable by the browser, because it differs from "
>>>>>> serverA.domainA.com".
>>>>>> So the browser ignores the cookie.
>>>>>>
>>>>>> That issue would be solved, if the content of the <iframe> appeared to
>>>>>> the
>>>>>> browser as also come from "serverA.domainA.com" (like the main
>>>>>> window's
>>>>>> content), wouldn't it ?
>>>>>>
>>>>>> If so, why not make the server "serverA.domainA.com" act as a reverse
>>>>>> proxy for the server serverB.domainB.com, and load the <iframe> from
>>>>>> serverA too ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
Because if they are reverse proxying on a subdomain then the subdomain
needs a ssl cert basically.
On Tue, Mar 31, 2015 at 5:35 PM, André Warnier <aw...@ice-sa.com> wrote:
> Wesley Acheson wrote:
>
>> This is getting off topic. The website that surrounds our website is
>> available under multiple domains. I.e. They white label their product.
>>
>
> Hi. If you do not want to pursue this, I cannot and do not want to force
> you.
> But on the base of the scarce info available : if they are the surrounding
> site, and your application lives in the <iframe>, then all they have to do
> is set up *their* server as the proxy to you, not so ?
> And in that case, why would they need to get any more certs than they
> already have ?
>
>
>
>> On Tue, Mar 31, 2015 at 4:52 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>> Wesley Acheson wrote:
>>>
>>> Andre that works perfectly fine but not for our use case.
>>>>
>>>> Ok, thanks for the confirmation. My logical world is back on track now.
>>> Not to nitpick, but your previous post was the first one in which you
>>> mentioned SSL as part of the equation, wasn't it ?
>>>
>>> If you still have a moment : in that previous post, you wrote "Its not
>>> pratical for us to mandate that they buy an SSL cert for every top level
>>> domain that contains our application."
>>> Could you in a few words explain why that would be necessary ?
>>> I guess that I still do not clearly see that use case. Maybe just having
>>> a look at the initial page which you mention, could help ?
>>>
>>>
>>> On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>>
>>>> Christopher Schultz wrote:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>
>>>>>> Hash: SHA256
>>>>>>
>>>>>> André,
>>>>>>
>>>>>> On 3/30/15 6:07 PM, André Warnier wrote:
>>>>>>
>>>>>> Christopher Schultz wrote:
>>>>>>
>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>
>>>>>>>> Jeffrey,
>>>>>>>>
>>>>>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>>>>>
>>>>>>>> -----Original Message----- From: Christopher Schultz [mailto:
>>>>>>>> chris@
>>>>>>>>
>>>>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>>>>>> Session Id
>>>>>>>>>>
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>>>>
>>>>>>>>>> Wesley,
>>>>>>>>>>
>>>>>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>>>>>
>>>>>>>>>>> chris@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.
>>>>>>>>>>>>
>>>>>>>>>>>> Okay, that explains it.
>>>>>>>>>>>>
>>>>>>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>>>>>
>>>>>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>>>>>> really no difference from a security perspective of
>>>>>>>>>> any of these strategies.
>>>>>>>>>>
>>>>>>>>>> - -chris
>>>>>>>>>>
>>>>>>>>>> I may be being a little naïve here, but would the
>>>>>>>>>>
>>>>>>>>> sessionCookieDomain
>>>>>>>>> parameter of the <Context> element work for
>>>>>>>>> the OP here?
>>>>>>>>>
>>>>>>>>> No, because the "domain" of the "page" is considered to be
>>>>>>>>>
>>>>>>>> separate from the application being used, here (in an <iframe>).
>>>>>>>> Setting the domain of the cookie to the page-domain would
>>>>>>>> probably result in the cookie being (possibly) ignored by the
>>>>>>>> browser (because it came from the wrong domain) or the cookie
>>>>>>>> wouldn't be sent to the application because the domain wouldn't
>>>>>>>> match.
>>>>>>>>
>>>>>>>> That does bring-up another point, though: could the page-domain
>>>>>>>> be used to proxy requests through to the application? If so, none
>>>>>>>> of this work might need to be done. The browser would request
>>>>>>>> https://host.com/app and host.com would proxy through to
>>>>>>>> https://otherhost.com/app. It's more configuration and
>>>>>>>> networking work, but it's less application work which may be a
>>>>>>>> win.
>>>>>>>>
>>>>>>>> Re-reading this thread from the beginning, I still have a doubt as
>>>>>>>>
>>>>>>>> to whether I understand the issue correctly. That is because, as
>>>>>>> far as I know, an <iframe> within a Windows, is its own Window
>>>>>>> object, with its own "baseURI" etc.. And from the server's point of
>>>>>>> view, it is in fact like a separate "browser window", from which
>>>>>>> requests originate and to which responses are being sent, and it is
>>>>>>> for all intents and purposes indistinguishable from just another
>>>>>>> separate Window or Tab that would be opened on the same workstation
>>>>>>> by the same or another browser. So under what circumstances can a
>>>>>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>>>>>> considered as a third-party cookie and blocked by a browser ? (And
>>>>>>> if it were, would that not be a browser bug ?)
>>>>>>>
>>>>>>> http://www.mendoweb.be/blog/internet-explorer-safari-
>>>>>>>
>>>>>> third-party-cookie-
>>>>>> problem/
>>>>>> http://stackoverflow.com/a/486569/276232
>>>>>>
>>>>>> Wesley, it looks like there are some hacks available that might solve
>>>>>> your problem.
>>>>>>
>>>>>> http://stackoverflow.com/a/4702110/276232
>>>>>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>>>>>
>>>>>> Unfortunately, it looks like these hacks are outdated and no longer
>>>>>> work: WebKit patched this "bug" so that iframe cookies are again
>>>>>> ignored
>>>>>> ..
>>>>>>
>>>>>> It looks like there might be some other possibilities, but I can't
>>>>>> verify them ATM.
>>>>>>
>>>>>>
>>>>>> So I would consider this as a browser bug. But nevertheless, that's
>>>>>>
>>>>> how
>>>>> they work and one has to live with this for now. So back to the
>>>>> drawing
>>>>> board.
>>>>> The question here is : do the browsers reject the cookie
>>>>> a) just because it is addressed to an <iframe> ?
>>>>> or
>>>>> b) because (while being addressed to an <iframe>) the "domain" part of
>>>>> that cookie is determined to be different from the one from which the
>>>>> main
>>>>> window content is coming ?
>>>>>
>>>>> If (b), then the easiest solution would be to make it so that it isn't
>>>>> so..
>>>>>
>>>>> Let's imagine that the first main page is seen by the browser as coming
>>>>> from "http://serverA.domainA.com", and that this contains an <iframe>
>>>>> loaded from "http://serverB.domainB.com". With the response going to
>>>>> the
>>>>> iframe, comes a session-id cookie, whose domain portion is also "
>>>>> serverB.domainB.com", and this is (dubiously in my view) determined to
>>>>> be
>>>>> unacceptable by the browser, because it differs from "
>>>>> serverA.domainA.com".
>>>>> So the browser ignores the cookie.
>>>>>
>>>>> That issue would be solved, if the content of the <iframe> appeared to
>>>>> the
>>>>> browser as also come from "serverA.domainA.com" (like the main
>>>>> window's
>>>>> content), wouldn't it ?
>>>>>
>>>>> If so, why not make the server "serverA.domainA.com" act as a reverse
>>>>> proxy for the server serverB.domainB.com, and load the <iframe> from
>>>>> serverA too ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Wesley Acheson wrote:
> This is getting off topic. The website that surrounds our website is
> available under multiple domains. I.e. They white label their product.
Hi. If you do not want to pursue this, I cannot and do not want to force you.
But on the base of the scarce info available : if they are the surrounding site, and your
application lives in the <iframe>, then all they have to do is set up *their* server as
the proxy to you, not so ?
And in that case, why would they need to get any more certs than they already have ?
>
> On Tue, Mar 31, 2015 at 4:52 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Wesley Acheson wrote:
>>
>>> Andre that works perfectly fine but not for our use case.
>>>
>> Ok, thanks for the confirmation. My logical world is back on track now.
>> Not to nitpick, but your previous post was the first one in which you
>> mentioned SSL as part of the equation, wasn't it ?
>>
>> If you still have a moment : in that previous post, you wrote "Its not
>> pratical for us to mandate that they buy an SSL cert for every top level
>> domain that contains our application."
>> Could you in a few words explain why that would be necessary ?
>> I guess that I still do not clearly see that use case. Maybe just having
>> a look at the initial page which you mention, could help ?
>>
>>
>>> On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>
>>> Christopher Schultz wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> André,
>>>>>
>>>>> On 3/30/15 6:07 PM, André Warnier wrote:
>>>>>
>>>>> Christopher Schultz wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>> Jeffrey,
>>>>>>>
>>>>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>>>>
>>>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>>>>> Session Id
>>>>>>>>>
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>>>
>>>>>>>>> Wesley,
>>>>>>>>>
>>>>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>>>>> chris@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.
>>>>>>>>>>>
>>>>>>>>>>> Okay, that explains it.
>>>>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>>>>
>>>>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>>>>> really no difference from a security perspective of
>>>>>>>>> any of these strategies.
>>>>>>>>>
>>>>>>>>> - -chris
>>>>>>>>>
>>>>>>>>> I may be being a little naïve here, but would the
>>>>>>>> sessionCookieDomain
>>>>>>>> parameter of the <Context> element work for
>>>>>>>> the OP here?
>>>>>>>>
>>>>>>>> No, because the "domain" of the "page" is considered to be
>>>>>>> separate from the application being used, here (in an <iframe>).
>>>>>>> Setting the domain of the cookie to the page-domain would
>>>>>>> probably result in the cookie being (possibly) ignored by the
>>>>>>> browser (because it came from the wrong domain) or the cookie
>>>>>>> wouldn't be sent to the application because the domain wouldn't
>>>>>>> match.
>>>>>>>
>>>>>>> That does bring-up another point, though: could the page-domain
>>>>>>> be used to proxy requests through to the application? If so, none
>>>>>>> of this work might need to be done. The browser would request
>>>>>>> https://host.com/app and host.com would proxy through to
>>>>>>> https://otherhost.com/app. It's more configuration and
>>>>>>> networking work, but it's less application work which may be a
>>>>>>> win.
>>>>>>>
>>>>>>> Re-reading this thread from the beginning, I still have a doubt as
>>>>>>>
>>>>>> to whether I understand the issue correctly. That is because, as
>>>>>> far as I know, an <iframe> within a Windows, is its own Window
>>>>>> object, with its own "baseURI" etc.. And from the server's point of
>>>>>> view, it is in fact like a separate "browser window", from which
>>>>>> requests originate and to which responses are being sent, and it is
>>>>>> for all intents and purposes indistinguishable from just another
>>>>>> separate Window or Tab that would be opened on the same workstation
>>>>>> by the same or another browser. So under what circumstances can a
>>>>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>>>>> considered as a third-party cookie and blocked by a browser ? (And
>>>>>> if it were, would that not be a browser bug ?)
>>>>>>
>>>>>> http://www.mendoweb.be/blog/internet-explorer-safari-
>>>>> third-party-cookie-
>>>>> problem/
>>>>> http://stackoverflow.com/a/486569/276232
>>>>>
>>>>> Wesley, it looks like there are some hacks available that might solve
>>>>> your problem.
>>>>>
>>>>> http://stackoverflow.com/a/4702110/276232
>>>>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>>>>
>>>>> Unfortunately, it looks like these hacks are outdated and no longer
>>>>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>>>>> ..
>>>>>
>>>>> It looks like there might be some other possibilities, but I can't
>>>>> verify them ATM.
>>>>>
>>>>>
>>>>> So I would consider this as a browser bug. But nevertheless, that's
>>>> how
>>>> they work and one has to live with this for now. So back to the drawing
>>>> board.
>>>> The question here is : do the browsers reject the cookie
>>>> a) just because it is addressed to an <iframe> ?
>>>> or
>>>> b) because (while being addressed to an <iframe>) the "domain" part of
>>>> that cookie is determined to be different from the one from which the
>>>> main
>>>> window content is coming ?
>>>>
>>>> If (b), then the easiest solution would be to make it so that it isn't
>>>> so..
>>>>
>>>> Let's imagine that the first main page is seen by the browser as coming
>>>> from "http://serverA.domainA.com", and that this contains an <iframe>
>>>> loaded from "http://serverB.domainB.com". With the response going to the
>>>> iframe, comes a session-id cookie, whose domain portion is also "
>>>> serverB.domainB.com", and this is (dubiously in my view) determined to
>>>> be
>>>> unacceptable by the browser, because it differs from "
>>>> serverA.domainA.com".
>>>> So the browser ignores the cookie.
>>>>
>>>> That issue would be solved, if the content of the <iframe> appeared to
>>>> the
>>>> browser as also come from "serverA.domainA.com" (like the main window's
>>>> content), wouldn't it ?
>>>>
>>>> If so, why not make the server "serverA.domainA.com" act as a reverse
>>>> proxy for the server serverB.domainB.com, and load the <iframe> from
>>>> serverA too ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
This is getting off topic. The website that surrounds our website is
available under multiple domains. I.e. They white label their product.
On Tue, Mar 31, 2015 at 4:52 PM, André Warnier <aw...@ice-sa.com> wrote:
> Wesley Acheson wrote:
>
>> Andre that works perfectly fine but not for our use case.
>>
>
> Ok, thanks for the confirmation. My logical world is back on track now.
> Not to nitpick, but your previous post was the first one in which you
> mentioned SSL as part of the equation, wasn't it ?
>
> If you still have a moment : in that previous post, you wrote "Its not
> pratical for us to mandate that they buy an SSL cert for every top level
> domain that contains our application."
> Could you in a few words explain why that would be necessary ?
> I guess that I still do not clearly see that use case. Maybe just having
> a look at the initial page which you mention, could help ?
>
>
>> On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>> Christopher Schultz wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> André,
>>>>
>>>> On 3/30/15 6:07 PM, André Warnier wrote:
>>>>
>>>> Christopher Schultz wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>
>>>>>> Jeffrey,
>>>>>>
>>>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>>>
>>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>>>
>>>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>>>> Session Id
>>>>>>>>
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>>
>>>>>>>> Wesley,
>>>>>>>>
>>>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>>>
>>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>>>> chris@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.
>>>>>>>>>>
>>>>>>>>>> Okay, that explains it.
>>>>>>>>>
>>>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>>>
>>>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>>>> really no difference from a security perspective of
>>>>>>>> any of these strategies.
>>>>>>>>
>>>>>>>> - -chris
>>>>>>>>
>>>>>>>> I may be being a little naïve here, but would the
>>>>>>> sessionCookieDomain
>>>>>>> parameter of the <Context> element work for
>>>>>>> the OP here?
>>>>>>>
>>>>>>> No, because the "domain" of the "page" is considered to be
>>>>>> separate from the application being used, here (in an <iframe>).
>>>>>> Setting the domain of the cookie to the page-domain would
>>>>>> probably result in the cookie being (possibly) ignored by the
>>>>>> browser (because it came from the wrong domain) or the cookie
>>>>>> wouldn't be sent to the application because the domain wouldn't
>>>>>> match.
>>>>>>
>>>>>> That does bring-up another point, though: could the page-domain
>>>>>> be used to proxy requests through to the application? If so, none
>>>>>> of this work might need to be done. The browser would request
>>>>>> https://host.com/app and host.com would proxy through to
>>>>>> https://otherhost.com/app. It's more configuration and
>>>>>> networking work, but it's less application work which may be a
>>>>>> win.
>>>>>>
>>>>>> Re-reading this thread from the beginning, I still have a doubt as
>>>>>>
>>>>> to whether I understand the issue correctly. That is because, as
>>>>> far as I know, an <iframe> within a Windows, is its own Window
>>>>> object, with its own "baseURI" etc.. And from the server's point of
>>>>> view, it is in fact like a separate "browser window", from which
>>>>> requests originate and to which responses are being sent, and it is
>>>>> for all intents and purposes indistinguishable from just another
>>>>> separate Window or Tab that would be opened on the same workstation
>>>>> by the same or another browser. So under what circumstances can a
>>>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>>>> considered as a third-party cookie and blocked by a browser ? (And
>>>>> if it were, would that not be a browser bug ?)
>>>>>
>>>>> http://www.mendoweb.be/blog/internet-explorer-safari-
>>>> third-party-cookie-
>>>> problem/
>>>> http://stackoverflow.com/a/486569/276232
>>>>
>>>> Wesley, it looks like there are some hacks available that might solve
>>>> your problem.
>>>>
>>>> http://stackoverflow.com/a/4702110/276232
>>>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>>>
>>>> Unfortunately, it looks like these hacks are outdated and no longer
>>>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>>>> ..
>>>>
>>>> It looks like there might be some other possibilities, but I can't
>>>> verify them ATM.
>>>>
>>>>
>>>> So I would consider this as a browser bug. But nevertheless, that's
>>> how
>>> they work and one has to live with this for now. So back to the drawing
>>> board.
>>> The question here is : do the browsers reject the cookie
>>> a) just because it is addressed to an <iframe> ?
>>> or
>>> b) because (while being addressed to an <iframe>) the "domain" part of
>>> that cookie is determined to be different from the one from which the
>>> main
>>> window content is coming ?
>>>
>>> If (b), then the easiest solution would be to make it so that it isn't
>>> so..
>>>
>>> Let's imagine that the first main page is seen by the browser as coming
>>> from "http://serverA.domainA.com", and that this contains an <iframe>
>>> loaded from "http://serverB.domainB.com". With the response going to the
>>> iframe, comes a session-id cookie, whose domain portion is also "
>>> serverB.domainB.com", and this is (dubiously in my view) determined to
>>> be
>>> unacceptable by the browser, because it differs from "
>>> serverA.domainA.com".
>>> So the browser ignores the cookie.
>>>
>>> That issue would be solved, if the content of the <iframe> appeared to
>>> the
>>> browser as also come from "serverA.domainA.com" (like the main window's
>>> content), wouldn't it ?
>>>
>>> If so, why not make the server "serverA.domainA.com" act as a reverse
>>> proxy for the server serverB.domainB.com, and load the <iframe> from
>>> serverA too ?
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Wesley Acheson wrote:
> Andre that works perfectly fine but not for our use case.
Ok, thanks for the confirmation. My logical world is back on track now.
Not to nitpick, but your previous post was the first one in which you mentioned SSL as
part of the equation, wasn't it ?
If you still have a moment : in that previous post, you wrote "Its not pratical for us to
mandate that they buy an SSL cert for every top level domain that contains our application."
Could you in a few words explain why that would be necessary ?
I guess that I still do not clearly see that use case. Maybe just having a look at the
initial page which you mention, could help ?
>
> On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Christopher Schultz wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> André,
>>>
>>> On 3/30/15 6:07 PM, André Warnier wrote:
>>>
>>>> Christopher Schultz wrote:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>
>>>>> Jeffrey,
>>>>>
>>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>>
>>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>>> Session Id
>>>>>>>
>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>
>>>>>>> Wesley,
>>>>>>>
>>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>>
>>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>>> chris@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.
>>>>>>>>>
>>>>>>>> Okay, that explains it.
>>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>>
>>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>>> really no difference from a security perspective of
>>>>>>> any of these strategies.
>>>>>>>
>>>>>>> - -chris
>>>>>>>
>>>>>> I may be being a little naïve here, but would the sessionCookieDomain
>>>>>> parameter of the <Context> element work for
>>>>>> the OP here?
>>>>>>
>>>>> No, because the "domain" of the "page" is considered to be
>>>>> separate from the application being used, here (in an <iframe>).
>>>>> Setting the domain of the cookie to the page-domain would
>>>>> probably result in the cookie being (possibly) ignored by the
>>>>> browser (because it came from the wrong domain) or the cookie
>>>>> wouldn't be sent to the application because the domain wouldn't
>>>>> match.
>>>>>
>>>>> That does bring-up another point, though: could the page-domain
>>>>> be used to proxy requests through to the application? If so, none
>>>>> of this work might need to be done. The browser would request
>>>>> https://host.com/app and host.com would proxy through to
>>>>> https://otherhost.com/app. It's more configuration and
>>>>> networking work, but it's less application work which may be a
>>>>> win.
>>>>>
>>>>> Re-reading this thread from the beginning, I still have a doubt as
>>>> to whether I understand the issue correctly. That is because, as
>>>> far as I know, an <iframe> within a Windows, is its own Window
>>>> object, with its own "baseURI" etc.. And from the server's point of
>>>> view, it is in fact like a separate "browser window", from which
>>>> requests originate and to which responses are being sent, and it is
>>>> for all intents and purposes indistinguishable from just another
>>>> separate Window or Tab that would be opened on the same workstation
>>>> by the same or another browser. So under what circumstances can a
>>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>>> considered as a third-party cookie and blocked by a browser ? (And
>>>> if it were, would that not be a browser bug ?)
>>>>
>>> http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
>>> problem/
>>> http://stackoverflow.com/a/486569/276232
>>>
>>> Wesley, it looks like there are some hacks available that might solve
>>> your problem.
>>>
>>> http://stackoverflow.com/a/4702110/276232
>>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>>
>>> Unfortunately, it looks like these hacks are outdated and no longer
>>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>>> ..
>>>
>>> It looks like there might be some other possibilities, but I can't
>>> verify them ATM.
>>>
>>>
>> So I would consider this as a browser bug. But nevertheless, that's how
>> they work and one has to live with this for now. So back to the drawing
>> board.
>> The question here is : do the browsers reject the cookie
>> a) just because it is addressed to an <iframe> ?
>> or
>> b) because (while being addressed to an <iframe>) the "domain" part of
>> that cookie is determined to be different from the one from which the main
>> window content is coming ?
>>
>> If (b), then the easiest solution would be to make it so that it isn't so..
>>
>> Let's imagine that the first main page is seen by the browser as coming
>> from "http://serverA.domainA.com", and that this contains an <iframe>
>> loaded from "http://serverB.domainB.com". With the response going to the
>> iframe, comes a session-id cookie, whose domain portion is also "
>> serverB.domainB.com", and this is (dubiously in my view) determined to be
>> unacceptable by the browser, because it differs from "serverA.domainA.com".
>> So the browser ignores the cookie.
>>
>> That issue would be solved, if the content of the <iframe> appeared to the
>> browser as also come from "serverA.domainA.com" (like the main window's
>> content), wouldn't it ?
>>
>> If so, why not make the server "serverA.domainA.com" act as a reverse
>> proxy for the server serverB.domainB.com, and load the <iframe> from
>> serverA too ?
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
Andre that works perfectly fine but not for our use case.
On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <aw...@ice-sa.com> wrote:
> Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> André,
>>
>> On 3/30/15 6:07 PM, André Warnier wrote:
>>
>>> Christopher Schultz wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>
>>>> Jeffrey,
>>>>
>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>
>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>> Session Id
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>
>>>>>> Wesley,
>>>>>>
>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>> chris@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.
>>>>>>>>
>>>>>>> Okay, that explains it.
>>>>>>
>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>
>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>> really no difference from a security perspective of
>>>>>> any of these strategies.
>>>>>>
>>>>>> - -chris
>>>>>>
>>>>> I may be being a little naïve here, but would the sessionCookieDomain
>>>>> parameter of the <Context> element work for
>>>>> the OP here?
>>>>>
>>>> No, because the "domain" of the "page" is considered to be
>>>> separate from the application being used, here (in an <iframe>).
>>>> Setting the domain of the cookie to the page-domain would
>>>> probably result in the cookie being (possibly) ignored by the
>>>> browser (because it came from the wrong domain) or the cookie
>>>> wouldn't be sent to the application because the domain wouldn't
>>>> match.
>>>>
>>>> That does bring-up another point, though: could the page-domain
>>>> be used to proxy requests through to the application? If so, none
>>>> of this work might need to be done. The browser would request
>>>> https://host.com/app and host.com would proxy through to
>>>> https://otherhost.com/app. It's more configuration and
>>>> networking work, but it's less application work which may be a
>>>> win.
>>>>
>>>> Re-reading this thread from the beginning, I still have a doubt as
>>> to whether I understand the issue correctly. That is because, as
>>> far as I know, an <iframe> within a Windows, is its own Window
>>> object, with its own "baseURI" etc.. And from the server's point of
>>> view, it is in fact like a separate "browser window", from which
>>> requests originate and to which responses are being sent, and it is
>>> for all intents and purposes indistinguishable from just another
>>> separate Window or Tab that would be opened on the same workstation
>>> by the same or another browser. So under what circumstances can a
>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>> considered as a third-party cookie and blocked by a browser ? (And
>>> if it were, would that not be a browser bug ?)
>>>
>>
>> http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
>> problem/
>> http://stackoverflow.com/a/486569/276232
>>
>> Wesley, it looks like there are some hacks available that might solve
>> your problem.
>>
>> http://stackoverflow.com/a/4702110/276232
>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>
>> Unfortunately, it looks like these hacks are outdated and no longer
>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>> ..
>>
>> It looks like there might be some other possibilities, but I can't
>> verify them ATM.
>>
>>
> So I would consider this as a browser bug. But nevertheless, that's how
> they work and one has to live with this for now. So back to the drawing
> board.
> The question here is : do the browsers reject the cookie
> a) just because it is addressed to an <iframe> ?
> or
> b) because (while being addressed to an <iframe>) the "domain" part of
> that cookie is determined to be different from the one from which the main
> window content is coming ?
>
> If (b), then the easiest solution would be to make it so that it isn't so.
>
> Let's imagine that the first main page is seen by the browser as coming
> from "http://serverA.domainA.com", and that this contains an <iframe>
> loaded from "http://serverB.domainB.com". With the response going to the
> iframe, comes a session-id cookie, whose domain portion is also "
> serverB.domainB.com", and this is (dubiously in my view) determined to be
> unacceptable by the browser, because it differs from "serverA.domainA.com".
> So the browser ignores the cookie.
>
> That issue would be solved, if the content of the <iframe> appeared to the
> browser as also come from "serverA.domainA.com" (like the main window's
> content), wouldn't it ?
>
> If so, why not make the server "serverA.domainA.com" act as a reverse
> proxy for the server serverB.domainB.com, and load the <iframe> from
> serverA too ?
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 3/30/15 6:07 PM, André Warnier wrote:
>> Christopher Schultz wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Jeffrey,
>>>
>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>> -----Original Message----- From: Christopher Schultz
>>>>> [mailto:chris@christopherschultz.net] Sent: Monday, March
>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>> Session Id
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>
>>>>> Wesley,
>>>>>
>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>> chris@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.
>>>>> Okay, that explains it.
>>>>>
>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>> unacceptable but not a request parameter? Or if it that you
>>>>> want to have the parameters be in POST-parameters only?
>>>>>
>>>>> In terms of forgery and/or capturing session identifiers,
>>>>> there's really no difference from a security perspective of
>>>>> any of these strategies.
>>>>>
>>>>> - -chris
>>>> I may be being a little naïve here, but would the
>>>> sessionCookieDomain parameter of the <Context> element work for
>>>> the OP here?
>>> No, because the "domain" of the "page" is considered to be
>>> separate from the application being used, here (in an <iframe>).
>>> Setting the domain of the cookie to the page-domain would
>>> probably result in the cookie being (possibly) ignored by the
>>> browser (because it came from the wrong domain) or the cookie
>>> wouldn't be sent to the application because the domain wouldn't
>>> match.
>>>
>>> That does bring-up another point, though: could the page-domain
>>> be used to proxy requests through to the application? If so, none
>>> of this work might need to be done. The browser would request
>>> https://host.com/app and host.com would proxy through to
>>> https://otherhost.com/app. It's more configuration and
>>> networking work, but it's less application work which may be a
>>> win.
>>>
>> Re-reading this thread from the beginning, I still have a doubt as
>> to whether I understand the issue correctly. That is because, as
>> far as I know, an <iframe> within a Windows, is its own Window
>> object, with its own "baseURI" etc.. And from the server's point of
>> view, it is in fact like a separate "browser window", from which
>> requests originate and to which responses are being sent, and it is
>> for all intents and purposes indistinguishable from just another
>> separate Window or Tab that would be opened on the same workstation
>> by the same or another browser. So under what circumstances can a
>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>> considered as a third-party cookie and blocked by a browser ? (And
>> if it were, would that not be a browser bug ?)
>
> http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
> problem/
> http://stackoverflow.com/a/486569/276232
>
> Wesley, it looks like there are some hacks available that might solve
> your problem.
>
> http://stackoverflow.com/a/4702110/276232
> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>
> Unfortunately, it looks like these hacks are outdated and no longer
> work: WebKit patched this "bug" so that iframe cookies are again ignored
> ..
>
> It looks like there might be some other possibilities, but I can't
> verify them ATM.
>
So I would consider this as a browser bug. But nevertheless, that's how they work and one
has to live with this for now. So back to the drawing board.
The question here is : do the browsers reject the cookie
a) just because it is addressed to an <iframe> ?
or
b) because (while being addressed to an <iframe>) the "domain" part of that cookie is
determined to be different from the one from which the main window content is coming ?
If (b), then the easiest solution would be to make it so that it isn't so.
Let's imagine that the first main page is seen by the browser as coming from
"http://serverA.domainA.com", and that this contains an <iframe> loaded from
"http://serverB.domainB.com". With the response going to the iframe, comes a session-id
cookie, whose domain portion is also "serverB.domainB.com", and this is (dubiously in my
view) determined to be unacceptable by the browser, because it differs from
"serverA.domainA.com". So the browser ignores the cookie.
That issue would be solved, if the content of the <iframe> appeared to the browser as also
come from "serverA.domainA.com" (like the main window's content), wouldn't it ?
If so, why not make the server "serverA.domainA.com" act as a reverse proxy for the server
serverB.domainB.com, and load the <iframe> from serverA too ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 3/30/15 6:07 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Jeffrey,
>>
>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>> -----Original Message----- From: Christopher Schultz
>>>> [mailto:chris@christopherschultz.net] Sent: Monday, March
>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>> Session Id
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>
>>>> Wesley,
>>>>
>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>> chris@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.
>>>> Okay, that explains it.
>>>>
>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>> unacceptable but not a request parameter? Or if it that you
>>>> want to have the parameters be in POST-parameters only?
>>>>
>>>> In terms of forgery and/or capturing session identifiers,
>>>> there's really no difference from a security perspective of
>>>> any of these strategies.
>>>>
>>>> - -chris
>>> I may be being a little naïve here, but would the
>>> sessionCookieDomain parameter of the <Context> element work for
>>> the OP here?
>>
>> No, because the "domain" of the "page" is considered to be
>> separate from the application being used, here (in an <iframe>).
>> Setting the domain of the cookie to the page-domain would
>> probably result in the cookie being (possibly) ignored by the
>> browser (because it came from the wrong domain) or the cookie
>> wouldn't be sent to the application because the domain wouldn't
>> match.
>>
>> That does bring-up another point, though: could the page-domain
>> be used to proxy requests through to the application? If so, none
>> of this work might need to be done. The browser would request
>> https://host.com/app and host.com would proxy through to
>> https://otherhost.com/app. It's more configuration and
>> networking work, but it's less application work which may be a
>> win.
>>
>
> Re-reading this thread from the beginning, I still have a doubt as
> to whether I understand the issue correctly. That is because, as
> far as I know, an <iframe> within a Windows, is its own Window
> object, with its own "baseURI" etc.. And from the server's point of
> view, it is in fact like a separate "browser window", from which
> requests originate and to which responses are being sent, and it is
> for all intents and purposes indistinguishable from just another
> separate Window or Tab that would be opened on the same workstation
> by the same or another browser. So under what circumstances can a
> "session-id cookie" being sent by Tomcat to that "iframe Window" be
> considered as a third-party cookie and blocked by a browser ? (And
> if it were, would that not be a browser bug ?)
http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
problem/
http://stackoverflow.com/a/486569/276232
Wesley, it looks like there are some hacks available that might solve
your problem.
http://stackoverflow.com/a/4702110/276232
http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
Unfortunately, it looks like these hacks are outdated and no longer
work: WebKit patched this "bug" so that iframe cookies are again ignored
.
It looks like there might be some other possibilities, but I can't
verify them ATM.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVGo1RAAoJEBzwKT+lPKRYRMsQAL2/czwcAmb4rQh7iz4euvDJ
eI0Q+PpVX4qmn/d5C7DHH69OckELdQNooYlpZ/QmwTerSPary6BML/T6WHPy35L8
ZJsDEEO2d8Renem8AYbpRoGwH9KpHSrVa+Fx40sN+u0mh+28IbV7Iq8sPgIn6VlC
WFV/c+98l2l7FiM7AGes+JpN4NnRxcoHQQKBMX0Rv8Og5fjNGz+CLD0mQhiPo1yo
DJNhto7Xe2v9hmaJYsV30XPGEyi+SCrwbSQy+IcsLXFNKB9ZFHt3AiX5Ck3O2wz9
+x8dQXmHJLZPuU+Ew5jvrF3be0rXbwlaC1JO9StdxXUyk5abcJEPGaV4lUUNxPAs
dyo1j+5fm+TH0NcdD96EEMzLaN2+n3S5H4GsrXUESeyL95wLHUj1fvDxWUmoTx/9
xoN8VI+sj8NowjpskuIyTPuhZfdeScOjJq4WrzfpvpYQy8RoXjf223IM1TjH2Y7O
fC68nj4ogRQyPLuBxvPQRRp11JE9QK7iBMJ4zdqrd0z+DelnAxH0cEvJhwMzriwZ
QMpZKJeDq6WkScoVW2M8yeh+6cl0YqntIwGiJT49bdpLYpPQr51sVGC7R/Spk5Sl
doP9CJCHzfEmluhVNrvhVmPyI5AtUrq5J629Oz7A8TcqJaq15WB0xfQcuj/ASfBt
OtsaEQK2ycPRHLFqgbej
=po7U
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey,
>
> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>> -----Original Message----- From: Christopher Schultz
>>> [mailto:chris@christopherschultz.net] Sent: Monday, March 30,
>>> 2015 10:48 AM To: Tomcat Users List Subject: Re: Post Session Id
>>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Wesley,
>>>
>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>> chris@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.
>>> Okay, that explains it.
>>>
>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>> unacceptable but not a request parameter? Or if it that you want
>>> to have the parameters be in POST-parameters only?
>>>
>>> In terms of forgery and/or capturing session identifiers,
>>> there's really no difference from a security perspective of any
>>> of these strategies.
>>>
>>> - -chris
>> I may be being a little naïve here, but would the
>> sessionCookieDomain parameter of the <Context> element work for the
>> OP here?
>
> No, because the "domain" of the "page" is considered to be separate
> from the application being used, here (in an <iframe>). Setting the
> domain of the cookie to the page-domain would probably result in the
> cookie being (possibly) ignored by the browser (because it came from
> the wrong domain) or the cookie wouldn't be sent to the application
> because the domain wouldn't match.
>
> That does bring-up another point, though: could the page-domain be
> used to proxy requests through to the application? If so, none of this
> work might need to be done. The browser would request
> https://host.com/app and host.com would proxy through to
> https://otherhost.com/app. It's more configuration and networking
> work, but it's less application work which may be a win.
>
Re-reading this thread from the beginning, I still have a doubt as to whether I understand
the issue correctly.
That is because, as far as I know, an <iframe> within a Windows, is its own Window object,
with its own "baseURI" etc.. And from the server's point of view, it is in fact like a
separate "browser window", from which requests originate and to which responses are being
sent, and it is for all intents and purposes indistinguishable from just another separate
Window or Tab that would be opened on the same workstation by the same or another browser.
So under what circumstances can a "session-id cookie" being sent by Tomcat to that "iframe
Window" be considered as a third-party cookie and blocked by a browser ?
(And if it were, would that not be a browser bug ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Monday, March 30,
>> 2015 10:48 AM To: Tomcat Users List Subject: Re: Post Session Id
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Wesley,
>>
>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>> chris@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.
>>
>> Okay, that explains it.
>>
>> Let me ask you... why is a path parameter (;jsessionid=f00)
>> unacceptable but not a request parameter? Or if it that you want
>> to have the parameters be in POST-parameters only?
>>
>> In terms of forgery and/or capturing session identifiers,
>> there's really no difference from a security perspective of any
>> of these strategies.
>>
>> - -chris
>
> I may be being a little naïve here, but would the
> sessionCookieDomain parameter of the <Context> element work for the
> OP here?
No, because the "domain" of the "page" is considered to be separate
from the application being used, here (in an <iframe>). Setting the
domain of the cookie to the page-domain would probably result in the
cookie being (possibly) ignored by the browser (because it came from
the wrong domain) or the cookie wouldn't be sent to the application
because the domain wouldn't match.
That does bring-up another point, though: could the page-domain be
used to proxy requests through to the application? If so, none of this
work might need to be done. The browser would request
https://host.com/app and host.com would proxy through to
https://otherhost.com/app. It's more configuration and networking
work, but it's less application work which may be a win.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVGYQxAAoJEBzwKT+lPKRYPZoP/iWHtCQlURZrspVAi9LvtXYw
bkiJNkajkrYlPwIH5gbNXKbjMl1Y0tKkYJ2ba3+uxx80LpKOFBCCUP7dZQ1Te5tH
2VfsiidZp7VAwQAQgKw1UDCsg8lNdnFM8o6m5ClTXhIQluz6T1Acc0PBMDvdKvCE
prFyYZ2q6VhVgwG0+s1sdo6DLWgLbd/aD517MNO3qrlW8vE5zmeDfWejzqLJTsA7
MfwcmjuKDuTgJwScdBd5dcCNa8D9kLoyDs9b2AWTDRwKebBQE8yqKDfqNp6eFqCI
v6DdexpDZYeO0nbId6fFXbtsy9sZ3mbZmoALkGVjykxLEdRIm4gk3dDHzxRqTq8U
KyGfWvIprYNfHQx5ehK1bfovfCSQ8AAz2cRg0hAj1gyDUnKVGqe+9lFBeSB/Bw9T
F8FAYiBah66AVas1fEXv/MW0mmwySzDTSXhoTpm36TxF88vpQ49RPHx3F/hE6Hon
JKhnB3hLwAG4ti+lhg1+fFAfnpPKqajoRbuE/UXW0AT2Uk4fXEaBh3dTZQBD46SQ
iblxG498bjVuOPlMLuTOWa/Xu04sb6Eh5VO8WqcvSkXBJItFws+XUakwkMpHDpjx
Y0Fa93XSczs2ryPBD62uiJrzqXxtEc2V/gNMbgn+L42KEWs5W6xQlY+gRiuDj6F0
npXdJG3SwGNX/LWdXwEl
=swso
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Post Session Id
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Monday, March 30, 2015 10:48 AM
> To: Tomcat Users List
> Subject: Re: Post Session Id
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Wesley,
>
> On 3/30/15 3:57 AM, Wesley Acheson wrote:
> > On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
> > chris@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.
>
> Okay, that explains it.
>
> Let me ask you... why is a path parameter (;jsessionid=f00)
> unacceptable but not a request parameter? Or if it that you want to
> have the parameters be in POST-parameters only?
>
> In terms of forgery and/or capturing session identifiers, there's
> really no difference from a security perspective of any of these
> strategies.
>
> - -chris
I may be being a little naïve here, but would the sessionCookieDomain parameter of the <Context> element work for the OP here?
Jeff
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Wesley,
On 3/30/15 3:57 AM, Wesley Acheson wrote:
> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
> chris@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.
Okay, that explains it.
Let me ask you... why is a path parameter (;jsessionid=f00)
unacceptable but not a request parameter? Or if it that you want to
have the parameters be in POST-parameters only?
In terms of forgery and/or capturing session identifiers, there's
really no difference from a security perspective of any of these
strategies.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVGXArAAoJEBzwKT+lPKRYzcgQAJc4Kean12GHpSv63+I8TaVT
cNV7r7Rq+HYMpRIJG8qVFd95ic0/OVPkm5dueO7QpIA/EBVPSnWi/fItcZt9tXJq
m90salW0ey5jF8L8C9CTJ0z1j4PnSy9jlCIS/oU/9F2UrPGGUkeWdYy5lQWM+VDr
rPcjxvim7QBWg6+toATt9gnKeH3zHFoLkHF0DdMSlbO2Ro0GTO/Mm73iIXRiwvzc
hN1auq8Mb0WVXJPTnLGMIMg3+NF/F7mH8oFYhNh7JvmnFwXapLLZAteEKHkkWu+i
efUAU1mo2dlQcKasLUqAzcWIqg3UxW3rCGjHM6GoLnyr2C9nEf88wF3VI2FiwvxF
n2hVYwsA29gZSqlpIsYNDcJZ3NKFfKlTbGxzrjaP6FN8WvsLm6BpuIV1ssDsl/gy
tzEHyWVN4eJJe13QfuuSURE0FFlcpnl2rrYl60FJBnl2osNBWoepYwjjgRS0+3qL
wV5BqJMpDiTekEOAmxncA/DxDEIsWqDdDGCrvcMxWd3500HvV7KsdmEbnP7CKmPF
iuPvKrdZVb9QRH4Lzk0OQh/kS/pEAZjJXEy+Jgy07FlIYZs0G5DohkV/bTrU2OvX
ZfOYkOk+f/D644db0WAOd2M161YEUBBPctFYcuL18nS/7sfk4jh8boWb9vqzR7G3
7vdeoGUmCwolP/kl9zMO
=2l/K
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post Session Id
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post Session Id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
>.
> 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).
Or you could handle session-management yourself and not use
servlet-spec-style session-tracking (which would be WAY more invasive
to your 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.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org