Re: problems with partitioned cookies

[Christopher Schultz]

Holger,

On 3/19/24 04:46, info@klawitter.de wrote:

dang! I missed that while checking the changelog.
Thanks for pointing out.


I'm curious about CHIPS. It's still considered experimental and, 
honestly, every web browser on the planet is poised to use the 
equivalent of "partitioned cookies" for every site, everywhere, 
regardless of the "partitioned" flag on a Set-Cookie header.


Why do you have to bother modifying your application? It seems to be 
that CHIPS will die on the vine and will never become an official standard.


In fact, it looks like it has already died:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

https://datatracker.ietf.org/doc/html/draft-cutler-httpbis-partitioned-cookies 
[ "About This Document" -> "Latest Revision of this draft" -> 404 ]


Nobody has touched the spec on GitHub in 2 years: 
https://github.com/explainers-by-googlers/CHIPS-spec


... though this documentation has been updated as recently as 5 months 
ago: https://github.com/privacycg/CHIPS


-chris


Mark Thomas wrote (at 2024-03-18 17:03 +):

On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default
partitioned attribute wasn't added until 9.0.85.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: problems with partitioned cookies

[info . asf]

Hi Mark,

dang! I missed that while checking the changelog.
Thanks for pointing out.

Regards,
  Holger

Mark Thomas wrote (at 2024-03-18 17:03 +):
> On 18/03/2024 15:16, info@klawitter.de wrote:
>
> > What am I doing wrong here? (Tomcat 9.0.82)
>
> https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
>
> Search for "partitioned"
>
> The problem is you are using Tomcat 9.0.82. Support for a default
> partitioned attribute wasn't added until 9.0.85.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: problems with partitioned cookies

[Mark Thomas]

On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default 
partitioned attribute wasn't added until 9.0.85.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

problems with partitioned cookies

[info . asf]

Hi there,

I have to make my webapp complying to CHIPS. For this I am
trying to configure the CookieProcessor to allow partitioned cookies.

For this I added a CookieProcessor directive to the context.xml
like this:



However tomcat complains about this with
[Catalina-utility-1] org.apache.tomcat.util.digester.SetPropertiesRule.begin 
Match [Context/CookieProcessor] failed to set property [partitioned] to [true]

What am I doing wrong here? (Tomcat 9.0.82)

Regards,

  Holger

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXTERNAL] - Re: Partitioned cookies

[Christopher Schultz]

Mark,

On 12/15/23 04:03, Mark Thomas wrote:

On 14/12/2023 21:15, André van der Lugt wrote:


From: Chuck Caldarale <mailto:n82...@gmail.com>
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List <mailto:users@tomcat.apache.org>
Subject: [EXTERNAL] - Re: Partitioned cookies


On Nov 15, 2023, at 08:06, Adam Warfield
<mailto:awarf...@opentext.com.INVALID> wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie 
attribute
but starting in 2024, browsers will begin enforcing the newer 
"Partitioned"
attribute for third-party cookies. Is there a way to set this 
attribute within
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This 
affects

any webapps that are embedded within iframes across domains where those
cookies will be rejected if not partitioned.



Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/


expired this past May and no updated version has been submitted to 
IETF. Is
there some other active standards document describing cookie 
partitioning?


   - Chuck


Standard or not, Google/Chrome is moving on and will (as noted above) 
soon start to gradually reject third-party cookies without the 
Partitioned attribute.


I'm kindly asking the experts: is Tomcat support for this feature 
being planned?


No.


If not, what can be done to modestly prioritize it?


Open an enhancement request in Bugzilla. Better still, provide a PR to 
implement the change.


No need, right? Tomcat 10 has Cookie.setAttribute(), as I mentioned back 
on 2023-11-16 in response to the OP.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXTERNAL] - Re: Partitioned cookies

[Mark Thomas]

On 14/12/2023 21:15, André van der Lugt wrote:


From: Chuck Caldarale <mailto:n82...@gmail.com>
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List <mailto:users@tomcat.apache.org>
Subject: [EXTERNAL] - Re: Partitioned cookies


On Nov 15, 2023, at 08:06, Adam Warfield
<mailto:awarf...@opentext.com.INVALID> wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie attribute
but starting in 2024, browsers will begin enforcing the newer "Partitioned"
attribute for third-party cookies. Is there a way to set this attribute within
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects
any webapps that are embedded within iframes across domains where those
cookies will be rejected if not partitioned.



Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/


expired this past May and no updated version has been submitted to IETF. Is
there some other active standards document describing cookie partitioning?

   - Chuck


Standard or not, Google/Chrome is moving on and will (as noted above) soon 
start to gradually reject third-party cookies without the Partitioned attribute.

I'm kindly asking the experts: is Tomcat support for this feature being planned?


No.


If not, what can be done to modestly prioritize it?


Open an enhancement request in Bugzilla. Better still, provide a PR to 
implement the change.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [EXTERNAL] - Re: Partitioned cookies

[André van der Lugt]

> -Original Message-
> From: Adam Warfield 
> Sent: woensdag 15 november 2023 16:49
> To: Tomcat Users List 
> Subject: Re: [EXTERNAL] - Re: Partitioned cookies
> 
> That's strange. I was not aware the proposal had expired. I've been working
> off of a few pages as it seemed Chrome/Edge were moving forward with
> Firefox at least showing positive support without committing.
> 
> https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/
>   (October 2023)
>
> https://github.com/mozilla/standards-positions/issues/678  (Firefox showing 
> positive support, last updated 2022)
>
> https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies
>
> https://github.com/privacycg/CHIPS
> 
> 
> Adam
> 
> 
> From: Chuck Caldarale <mailto:n82...@gmail.com>
> Sent: Wednesday, November 15, 2023 9:48 AM
> To: Tomcat Users List <mailto:users@tomcat.apache.org>
> Subject: [EXTERNAL] - Re: Partitioned cookies
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe. If you feel that the email is suspicious, please report it 
> using
> PhishAlarm.
> 
> 
>> On Nov 15, 2023, at 08:06, Adam Warfield
>> <mailto:awarf...@opentext.com.INVALID> wrote:
>> 
>> The Rfc6265CookieProcessor supports setting the SameSite cookie attribute
>> but starting in 2024, browsers will begin enforcing the newer "Partitioned"
>> attribute for third-party cookies. Is there a way to set this attribute 
>> within
>> Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects
>> any webapps that are embedded within iframes across domains where those
>> cookies will be rejected if not partitioned.
> 
> 
> Looks like the CHIPS proposal:
> 
> https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/
> 
> 
> expired this past May and no updated version has been submitted to IETF. Is
> there some other active standards document describing cookie partitioning?
> 
>   - Chuck

Standard or not, Google/Chrome is moving on and will (as noted above) soon 
start to gradually reject third-party cookies without the Partitioned attribute.

I'm kindly asking the experts: is Tomcat support for this feature being 
planned? If not, what can be done to modestly prioritize it?

André


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Partitioned cookies

[Christopher Schultz]

Adam,

On 11/15/23 09:06, Adam Warfield wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie
attribute but starting in 2024, browsers will begin enforcing the
newer "Partitioned" attribute for third-party cookies.

Is there a way to set this attribute within Tomcat for things like the
JSESSIONID and XSRF-TOKEN cookies?


Wait... are you using cookies for CSRF tokens? That doesn't really 
provide much protection. Your CSRF cookie will be transmitted along with 
any request, even "forged" requests.


Are you responsible for the primary web application, here, or are you 
responsible for a third-party site such as an advertiser, back-end 
service, etc.?



This affects any webapps that are embedded within iframes across
domains where those cookies will be rejected if not partitioned.


If you migrate to Tomcat 10.1 or later (with Jakarta Servlet APIs), 
there is Cookie.setAttributeString name, String value)[1]


If you cannot upgrade to Tomcat 10 in time, then you can simply resort 
to setting the headers directly:


response.addHeader("Set-Cookie", "XSRF-TOKEN=foo; Partitioned");

-chris

[1] 
https://jakarta.ee/specifications/servlet/6.0/apidocs/jakarta.servlet/jakarta/servlet/http/cookie#setAttribute(java.lang.String,java.lang.String)


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXTERNAL] - Re: Partitioned cookies

[Adam Warfield]

That's strange. I was not aware the proposal had expired. I've been working off 
of a few pages as it seemed Chrome/Edge were moving forward with Firefox at 
least showing positive support without committing.

https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/
  (October 2023)

https://github.com/mozilla/standards-positions/issues/678  (Firefox showing 
positive support, last updated 2022)

https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies

https://github.com/privacycg/CHIPS


Adam


From: Chuck Caldarale 
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List 
Subject: [EXTERNAL] - Re: Partitioned cookies

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you feel that the email is suspicious, please report it using 
PhishAlarm.


On Nov 15, 2023, at 08:06, Adam Warfield  wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie attribute but 
starting in 2024, browsers will begin enforcing the newer "Partitioned" 
attribute for third-party cookies. Is there a way to set this attribute within 
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects any 
webapps that are embedded within iframes across domains where those cookies 
will be rejected if not partitioned.


Looks like the CHIPS proposal:

Cookies Having Independent Partitioned State 
specification<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/__;!!Obbck6kTJA!ZbFXogBE-lmZ3xovqF3YsoKYNLtMlNnrsEiA_SfTTvGWShrjsmioTAiQofWo4Ir5w1x4v6JfFDVDzeQ$>
datatracker.ietf.org<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/__;!!Obbck6kTJA!ZbFXogBE-lmZ3xovqF3YsoKYNLtMlNnrsEiA_SfTTvGWShrjsmioTAiQofWo4Ir5w1x4v6JfFDVDzeQ$>
[ietf-logo-nor-180.png]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/__;!!Obbck6kTJA!ZbFXogBE-lmZ3xovqF3YsoKYNLtMlNnrsEiA_SfTTvGWShrjsmioTAiQofWo4Ir5w1x4v6JfFDVDzeQ$>

expired this past May and no updated version has been submitted to IETF. Is 
there some other active standards document describing cookie partitioning?

  - Chuck

Re: Partitioned cookies

[Chuck Caldarale]

> On Nov 15, 2023, at 08:06, Adam Warfield  
> wrote:
> 
> The Rfc6265CookieProcessor supports setting the SameSite cookie attribute but 
> starting in 2024, browsers will begin enforcing the newer "Partitioned" 
> attribute for third-party cookies. Is there a way to set this attribute 
> within Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This 
> affects any webapps that are embedded within iframes across domains where 
> those cookies will be rejected if not partitioned.



Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

expired this past May and no updated version has been submitted to IETF. Is 
there some other active standards document describing cookie partitioning?

  - Chuck

Partitioned cookies

[Adam Warfield]

The Rfc6265CookieProcessor supports setting the SameSite cookie attribute but 
starting in 2024, browsers will begin enforcing the newer "Partitioned" 
attribute for third-party cookies. Is there a way to set this attribute within 
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects any 
webapps that are embedded within iframes across domains where those cookies 
will be rejected if not partitioned.

Adam

Re: SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Just to confirm, we know that Chrome will block JSESSIONID it if sent over
unsecure connection and with SameSite=None. But we saw the
previously mentioned issue in Firefox.

Thanks,

On Wed, 11 Mar 2020 at 15:33, M. Manna  wrote:

> Hi All,
>
> Due to the recent issues with Chrome 80, we have had to make some changes
> for our context.xml to have SameSite attribute setup for CookieProcessor
>
> What we've noticed is that even though CookieProcessorBase captures and
> assigns the correct value (e.g. "None" or "Lax"), the Network tab of
> browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
> you observe the response header, it's actually setting the correct value.
>
> The question is - Would this be expected? Or, do we have to fix something
> here for browsers?
>
> Regards,
> M. MAnna
>

SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Hi All,

Due to the recent issues with Chrome 80, we have had to make some changes
for our context.xml to have SameSite attribute setup for CookieProcessor

What we've noticed is that even though CookieProcessorBase captures and
assigns the correct value (e.g. "None" or "Lax"), the Network tab of
browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
you observe the response header, it's actually setting the correct value.

The question is - Would this be expected? Or, do we have to fix something
here for browsers?

Regards,
M. MAnna

Re: SameSite cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

M,

On 11/8/19 10:40, M. Manna wrote:
> Interesting question.
> 
> samesite attribute is also to protect cookies from possible
> cross-site attacks. Even if you have super domain cookies, using
> strict/lax shouldn't make any difference for you, or does it?

I was just thinking that it's obvious that Tomcat would handle the
JSESSIONID cookie with respect to the SameSite policy. But the
CookieProcessor affects *all* cookies for the whole application, not
just those created for session-tracking. Perhaps you want different
policies for different (types of) cookies.

I haven't really thought of any specific use-cases, honestly.

Mark's workaround of directly-generating the Set-Cookie response
header is obviously the answer if you want different policies for
different cookies. That just may require applications to be re-written
if the administrator wants to enable e.g. SameSite=Strict for the
JSESSIONID cookie, because there is no way to say "only apply this
policy to JSESSIONID cookies" or anything like that.

- -chris

> On Fri, 8 Nov 2019 at 15:04, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> All,
> 
> I'm looking at using "samesite" cookies within my application. It 
> looks as simple as setting the "sameSite" attribute appropriately
> on the CookieProcessor for the , which isn't there in a
> default configuration. So you just have to add it:
> 
> 
> 
> 
> 
> 
> 
> Cool, now my JSESSIONID cookies are coming back with the
> SameSite=Lax parameter.
> 
> But it also applies to all the other cookies my application
> creates. It looks like there is no way to set/reset this parameter
> on an individual-cookie basis. That would require a change to the
> Servlet API, right?
> 
> I'm okay with SameSite being applied to ALL my cookies, but maybe
> not everybody is. Are there any workarounds for this?
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FpCAACgkQHPApP6U8
pFjK7g/8COMS1JKF/X9eF9VP/ywSZV3cWJaCz5gMCzPcZC4TL+BVZIv21YdhpnjS
49rFUHz40fgq5RdRpnVLcVN0rqKYRtHHwrrmcndWqufIpiLYVC6kU8aUll/PO3Kc
pPfF2bseooz5HYoHQpYqWWYUfXGNS+wNSpjAmx9qd5zJKhc9YrT3yanTk1s8yF0i
jd0kguM0iN9G9MpZWctG0H7q+94xOxdluzbqvAemoN/7FhmhDHouMkRIZMfd4eRf
TfziHgQ1llr1kNUaMg6mS1f6eqWXHFVZFTbSJukpY2aKHQDbhdwN+l+zYI3Irb9H
Y0y3DRSUa1qZv5DNwFK8yGrM9A/Cj2dinnnL9BuOq4GmSw1JwDE7TBpz+Be7oE4d
CV/cj0raV2W9/Xtul7gVgJSKwkfsYsOwjcbbbmeLNcuNHYx6HE+OKhSIMjP+c3my
UyE9S6ZBa0TqI7Vd0IXXEGyRhwdtFQnNKAn7Ui69gn9zm0CbKNXk53zDImd42+At
8jLBicPyryny4Z07qHXm83O3TjjgY4JVJaSOC04sKdReIi3kcio5Co4sRTPfIXvZ
zbDCuMJq840ObS9WiIrZVhORF0Nd6M4XdfsA5+n+7/mRIwRGMI3v19ariKzT1GmD
XhGPxyGtDxydyIT3NGwC/SdzbMbdmCdgcNFTwkld5wohpQPMAIc=
=Lfm8
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SameSite cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/8/19 11:53, Mark Thomas wrote:
>> All,
>> 
>> I'm looking at using "samesite" cookies within my application.
>> It looks as simple as setting the "sameSite" attribute
>> appropriately on the CookieProcessor for the , which
>> isn't there in a default configuration. So you just have to add
>> it:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Cool, now my JSESSIONID cookies are coming back with the
>> SameSite=Lax parameter.
>> 
>> But it also applies to all the other cookies my application
>> creates. It looks like there is no way to set/reset this
>> parameter on an individual-cookie basis. That would require a
>> change to the Servlet API, right?
> 
> That would be one way to implement it - and then the app would have
> to (un)set it.
> 
> Per Cookie configuration in CookieProcessor would be another way.
> I haven't thought about how that might be implemented though.

It seems that there are enough cookie parameters that the servlet spec
doesn't support[1], it might not be a bad idea to propose two new
methods to be added to the Cookie class:

  public void setAttribute(String name, String value);
  public String getAttribute(String name);

Then, if e.g. SameSite isn't directly supported by the Cookie APi,
applications can still:

  Cookie cookie = new Cookie("my_cookie");
  cookie.setAttribute("SameSite", "Strict"); // or null

>> I'm okay with SameSite being applied to ALL my cookies, but maybe
>> not everybody is. Are there any workarounds for this?
> 
> Manually write your own cookie header.

Duh. Of course that will work :)

- -chris

[1] https://scotthelme.co.uk/tough-cookies/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FozMACgkQHPApP6U8
pFhuEBAAoGIEgFDoFfyKH85SySn/7GZEbw0EoM0lPL/09Hm9EiL4n00FBYRy/AiA
inSubQExqG+3iaNIXcBn/mQgAetCNOxXjNKeEvmcO9ljYLGAoExkqHomCSkMFEZL
AFNSei3+fYK4DHCciKKIC7n/IDbMCDxT8XM8or1rF0efvIyGa4leI9xZqew8yKjs
1/OnhsjvnLsctL/5NkBJkJF49W3Qk7Owl7tThyprqQjwnslGCXgm0gHL+/9JKERX
XSxlbsNTGgMAkx0tQU+jRPrO+nPC0FgotE8TZ7lVrpv65eMZ/hf7t7YaYlGWeaJl
EZPg8Uoigwze9vK3+C48z0ynHaBMPa/boLHfsxxgIdNGN0ouHrvFndVAzfvR9Rlk
jlmoWaAYzTqKUevosOE5sXHdlh0sHsv/DxB2DxT2v1FHiqZ2p7dyEWCzpa+BxovO
R7Ezj9l3ecVZkcmQn8UHT9nX3MZcCvjVf/EDYbiZS+TI6pq8PfMw8o5d+NO1JDIn
RtQ3mlJ7pUaqRK6+ItAGQssL9gSlUhcK/wyqXyaSCOx61eWxeKzo66YmOMi7bflV
Tz72DkSH/5Ml6AgMLiVBYA9qBtcApjMhHKYlZ+h/i2S+qKgATs8vTEfF3WZQWcV/
Eg05iDha/DpM5gcFzTewMhtNn/Hb+eR5UWHN6ogcY/YZ9qHwpx0=
=Ps3/
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SameSite cookies

[Mark Thomas]

> All,
> 
> I'm looking at using "samesite" cookies within my application. It
> looks as simple as setting the "sameSite" attribute appropriately on
> the CookieProcessor for the , which isn't there in a default
> configuration. So you just have to add it:
> 
> 
> 
>
> 
> 
> 
> Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
> parameter.
> 
> But it also applies to all the other cookies my application creates.
> It looks like there is no way to set/reset this parameter on an
> individual-cookie basis. That would require a change to the Servlet
> API, right?

That would be one way to implement it - and then the app would have to
(un)set it.

Per Cookie configuration in CookieProcessor would be another way. I
haven't thought about how that might be implemented though.

> I'm okay with SameSite being applied to ALL my cookies, but maybe not
> everybody is. Are there any workarounds for this?

Manually write your own cookie header.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SameSite cookies

[Rémy Maucherat]

On Fri, Nov 8, 2019 at 4:04 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm looking at using "samesite" cookies within my application. It
> looks as simple as setting the "sameSite" attribute appropriately on
> the CookieProcessor for the , which isn't there in a default
> configuration. So you just have to add it:
>
> 
>
>
>
> 
>
> Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
> parameter.
>
> But it also applies to all the other cookies my application creates.
> It looks like there is no way to set/reset this parameter on an
> individual-cookie basis. That would require a change to the Servlet
> API, right?
>
> I'm okay with SameSite being applied to ALL my cookies, but maybe not
> everybody is. Are there any workarounds for this?
>

The Servlet API has no remove cookie API. If you use a Valve, you can
remove cookies using Response.getCookies and then remove from the list.
But this is not really the problem here since the same site thing is added
when the cookie header is generated. You can extend the CookieGenerator to
add more flexibility for your use case maybe ?

Rémy

Re: SameSite cookies

[M. Manna]

Hey Chris,

Interesting question.

samesite attribute is also to protect cookies from possible cross-site
attacks. Even if you have super domain cookies, using strict/lax shouldn't
make any difference for you, or does it?

Thanks,

On Fri, 8 Nov 2019 at 15:04, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm looking at using "samesite" cookies within my application. It
> looks as simple as setting the "sameSite" attribute appropriately on
> the CookieProcessor for the , which isn't there in a default
> configuration. So you just have to add it:
>
> 
>
>
>
> 
>
> Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
> parameter.
>
> But it also applies to all the other cookies my application creates.
> It looks like there is no way to set/reset this parameter on an
> individual-cookie basis. That would require a change to the Servlet
> API, right?
>
> I'm okay with SameSite being applied to ALL my cookies, but maybe not
> everybody is. Are there any workarounds for this?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3Fg/kACgkQHPApP6U8
> pFjfYg/+LSQ1WHvr/Ds7yskd3C7AFF5jBZaNPO4+I3M+5urpQqvy0Gk2use136rA
> rEoct2iTauj2PY9oIplMUqFuaeiOiO5e0VE5//jp7FhnBe4yRxI0mUGzkvX/d/3j
> e37Hm257iiteJ7q19b0uCTd867ZD2dyxupZYHaNQpeviiV+kyGwsv9KupHeIDpyk
> E2AvZ/lIsRQ6tJ0jkNWiHBlpNgXVhIdabJ9WJHFbaqQ4oHPhcKZaMvthoDFnUKGS
> JpyZjmP9TbNjIWE2I2zhwkKC4lTsiHkpeyccR/UC1V4SQs63rUxpGRCGjQ/Jk4p9
> o6nCfI9zJuH3nsAV/sGasXuoPwzDpszsZT8Q8feun9jmfLz6aHynDR2b65Xq1dwc
> OjPX/5QSk6TrlgXQ0jnqlfIhWp1A9e8OF2HUEKW1XgmNFu5CWlsUSYdHlsMBNEF2
> gaciDa1IvYDnfmawJPgXxSUu6csBboiqRsr4RvCcjCSm4mERkcIm8UsYUHJG+c7Z
> IhWc3pszJ5e/IV/w1iVZK34JL+qZcTImR9gThViNJnECW7Y7E5xbYBTOqxkjUUFR
> 6AUvtaW9vMZe1ArsZKKWdpb1f/DjK70KeQsyVcK8zhYbQb8uSI818vo6LV7andpU
> bfifGiSSWuT1ZHdwMOaCrIf++ew1xc45yPb4qsZqTQ95jkuHhng=
> =QbXx
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

SameSite cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm looking at using "samesite" cookies within my application. It
looks as simple as setting the "sameSite" attribute appropriately on
the CookieProcessor for the , which isn't there in a default
configuration. So you just have to add it:



   



Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
parameter.

But it also applies to all the other cookies my application creates.
It looks like there is no way to set/reset this parameter on an
individual-cookie basis. That would require a change to the Servlet
API, right?

I'm okay with SameSite being applied to ALL my cookies, but maybe not
everybody is. Are there any workarounds for this?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3Fg/kACgkQHPApP6U8
pFjfYg/+LSQ1WHvr/Ds7yskd3C7AFF5jBZaNPO4+I3M+5urpQqvy0Gk2use136rA
rEoct2iTauj2PY9oIplMUqFuaeiOiO5e0VE5//jp7FhnBe4yRxI0mUGzkvX/d/3j
e37Hm257iiteJ7q19b0uCTd867ZD2dyxupZYHaNQpeviiV+kyGwsv9KupHeIDpyk
E2AvZ/lIsRQ6tJ0jkNWiHBlpNgXVhIdabJ9WJHFbaqQ4oHPhcKZaMvthoDFnUKGS
JpyZjmP9TbNjIWE2I2zhwkKC4lTsiHkpeyccR/UC1V4SQs63rUxpGRCGjQ/Jk4p9
o6nCfI9zJuH3nsAV/sGasXuoPwzDpszsZT8Q8feun9jmfLz6aHynDR2b65Xq1dwc
OjPX/5QSk6TrlgXQ0jnqlfIhWp1A9e8OF2HUEKW1XgmNFu5CWlsUSYdHlsMBNEF2
gaciDa1IvYDnfmawJPgXxSUu6csBboiqRsr4RvCcjCSm4mERkcIm8UsYUHJG+c7Z
IhWc3pszJ5e/IV/w1iVZK34JL+qZcTImR9gThViNJnECW7Y7E5xbYBTOqxkjUUFR
6AUvtaW9vMZe1ArsZKKWdpb1f/DjK70KeQsyVcK8zhYbQb8uSI818vo6LV7andpU
bfifGiSSWuT1ZHdwMOaCrIf++ew1xc45yPb4qsZqTQ95jkuHhng=
=QbXx
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

Chris - The header logging is a good idea. We'll add that. In the meantime,
it looks like it might have been premature to indicate that "the problem
persists with HTTP/1.1". The one instance that I found was a red herring,
so to date the problem has *not* recurred since addressing the HTTP/1.0
issue.

In re: our web server and Wireshark. We have an nginx instance sitting on a
separate (web server) machine. The Wireshark was the app server, so it was
capturing the traffic from nginx to Tomcat.

At any rate, I will be sure to keep you apprised as to the status.
Hopefully the HTTP/1.1 fix addresses the problem...

Chad

On Wed, Feb 28, 2018 at 8:17 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chad,
>
> On 2/27/18 9:02 PM, Chad Stansbury wrote:
> > Thanks for your response. Unfortunately it doesn't appear to be a
> > bad cookie name or value, as the identical set of cookies are
> > passed (and parsed correctly) on requests that immediately precede
> > and follow the failing request. That's pretty clear from both the
> > Wireshark and Tomcat access logs we have. What we're seeing is that
> > the client (which is a browser, usually Chrome) sends a burst of
> > requests, and occasionally one of those requests will fail as the
> > web app detects that is has no cookies even though the Wireshark
> > indicates that there are.  We even added logging to the
> > AccessLogValve to log the cookies that we're looking for, and it
> > yields an empty value... So we know that the cookie parsing is
> > either failing or the cookies get cleared following parsing, but
> > before being passed on to the AccessLogValve.
>
> Sounds like you have it at least semi-reproducible. That's great news.
>
> What about logging both the results of request.getCookies() as well as
> request.getHeader("Cookie")? If the parsing is failing, you will get
> no Cookie objects from request.getCookie(), but you should still get
> the header back from the request.
>
> If there is no header in the request... well, then maybe something is
> wrong elsewhere with the request, and Tomcat never gets to the Cookie
> header at all.
>
> > Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that
> > the problem persists even with HTTP/1.1. The one thing that I
> > failed to mention on the original note is that we're running Tomcat
> > on a Windows server. So I'm not sure if that has anything to do
> > with the issue that we're seeing or not...
>
> I wouldn't expect Windows to have anything to do with it, same for
> HTTP/1.0 versus HTTP/1.1... headers haven't changed much across HTTP
> versions, and Tomcat treats those headers the same regardless of the
> advertised version of the protocol. The biggest difference between
> HTTP/1.0 and HTTP/1.1 is that HTTP/1.1 has a few required headers.
>
> > That being said, I will double-check the catalina.out to see if we
> > can find any cookie parsing related errors.
>
> That would be good. Again, it will probably only be logged a single
> time, not every time. But if you have the opportunity to bounce Tomcat
> and hit it with a load that will likely cause an error to occur, you
> ought to be able to catch an error message -- if indeed Cookie-parsing
> is the problem. Or, if request-parsing is the problem, too.
>
> One more question: are you using a reverse-proxy like httpd out in
> front? Exactly where are you sampling with Wireshark?
>
> - -chris
>
> > On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Chad,
> >
> > On 2/27/18 9:44 AM, Chad Stansbury wrote:
> >>>> We've been troubleshooting an issue where our web application
> >>>> is getting a very occasional request that contains no cookies
> >>>> even though a Wireshark on the application server shows those
> >>>> cookies coming in on the request.
> >>>>
> >>>> I was able to replay the request that was captured via
> >>>> Wireshark, and when doing so, everything goes through just
> >>>> fine... so that rules out any sort of weird character set /
> >>>> header parsing issues.
> >>>>
> >>>> Environment specifics: Tomcat v7.0.77 running the (http-bio)
> >>>> connector
> >>>>
> >>>> Now here's the twist: Currently something in the site
> >>>> infrastructure has been configured to proxy to Tomcat with
> >>>> HTTP/1.0 instead of 1.1. We're trying to track that down and
> >>>> ad

Re: Tomcat 7 - Sporadic problem re: cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chad,

On 2/27/18 9:02 PM, Chad Stansbury wrote:
> Thanks for your response. Unfortunately it doesn't appear to be a
> bad cookie name or value, as the identical set of cookies are
> passed (and parsed correctly) on requests that immediately precede
> and follow the failing request. That's pretty clear from both the
> Wireshark and Tomcat access logs we have. What we're seeing is that
> the client (which is a browser, usually Chrome) sends a burst of
> requests, and occasionally one of those requests will fail as the
> web app detects that is has no cookies even though the Wireshark
> indicates that there are.  We even added logging to the
> AccessLogValve to log the cookies that we're looking for, and it
> yields an empty value... So we know that the cookie parsing is
> either failing or the cookies get cleared following parsing, but
> before being passed on to the AccessLogValve.

Sounds like you have it at least semi-reproducible. That's great news.

What about logging both the results of request.getCookies() as well as
request.getHeader("Cookie")? If the parsing is failing, you will get
no Cookie objects from request.getCookie(), but you should still get
the header back from the request.

If there is no header in the request... well, then maybe something is
wrong elsewhere with the request, and Tomcat never gets to the Cookie
header at all.

> Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that
> the problem persists even with HTTP/1.1. The one thing that I
> failed to mention on the original note is that we're running Tomcat
> on a Windows server. So I'm not sure if that has anything to do
> with the issue that we're seeing or not...

I wouldn't expect Windows to have anything to do with it, same for
HTTP/1.0 versus HTTP/1.1... headers haven't changed much across HTTP
versions, and Tomcat treats those headers the same regardless of the
advertised version of the protocol. The biggest difference between
HTTP/1.0 and HTTP/1.1 is that HTTP/1.1 has a few required headers.

> That being said, I will double-check the catalina.out to see if we
> can find any cookie parsing related errors.

That would be good. Again, it will probably only be logged a single
time, not every time. But if you have the opportunity to bounce Tomcat
and hit it with a load that will likely cause an error to occur, you
ought to be able to catch an error message -- if indeed Cookie-parsing
is the problem. Or, if request-parsing is the problem, too.

One more question: are you using a reverse-proxy like httpd out in
front? Exactly where are you sampling with Wireshark?

- -chris

> On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Chad,
> 
> On 2/27/18 9:44 AM, Chad Stansbury wrote:
>>>> We've been troubleshooting an issue where our web application
>>>> is getting a very occasional request that contains no cookies
>>>> even though a Wireshark on the application server shows those
>>>> cookies coming in on the request.
>>>> 
>>>> I was able to replay the request that was captured via
>>>> Wireshark, and when doing so, everything goes through just
>>>> fine... so that rules out any sort of weird character set /
>>>> header parsing issues.
>>>> 
>>>> Environment specifics: Tomcat v7.0.77 running the (http-bio) 
>>>> connector
>>>> 
>>>> Now here's the twist: Currently something in the site 
>>>> infrastructure has been configured to proxy to Tomcat with
>>>> HTTP/1.0 instead of 1.1. We're trying to track that down and
>>>> address that issue (for performance reasons), but in the mean
>>>> time, we're wondering whether or not this is a concurrency
>>>> issue related to protocol caching/recycling?
>>>> 
>>>> Has anyone ever seen anything like this before? Is there any 
>>>> legitimate scenario(s) where Tomcat will *not* parse out the 
>>>> cookies, but still route the request to the web app? Is this 
>>>> possible an edge condition that that might be caused by the
>>>> use of HTTP/1.0? Could this possibly be caused by the number
>>>> of maxThreads exceeding the `processorCache` value?
> 
> My immediate thought is that the cookie name or value contains a 
> character that causes parsing to fail within Tomcat. Do you have
> any information about which cookies appear to be being ignored by
> Tomcat (that is, not passed-on to the application) versus those
> that ARE available to the application?
> 
> Tomcat will generally log cookie-parsing errors to catalina.log,
> and possibly to the application's 

Re: Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

Hello Chris -

Thanks for your response. Unfortunately it doesn't appear to be a bad
cookie name or value, as the identical set of cookies are passed (and
parsed correctly) on requests that immediately precede and follow the
failing request. That's pretty clear from both the Wireshark and Tomcat
access logs we have. What we're seeing is that the client (which is a
browser, usually Chrome) sends a burst of requests, and occasionally one of
those requests will fail as the web app detects that is has no cookies even
though the Wireshark indicates that there are.  We even added logging to
the AccessLogValve to log the cookies that we're looking for, and it yields
an empty value... So we know that the cookie parsing is either failing or
the cookies get cleared following parsing, but before being passed on to
the AccessLogValve.

Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that the
problem persists even with HTTP/1.1. The one thing that I failed to mention
on the original note is that we're running Tomcat on a Windows server. So
I'm not sure if that has anything to do with the issue that we're seeing or
not...

That being said, I will double-check the catalina.out to see if we can find
any cookie parsing related errors.

Thanks, Chad

On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chad,
>
> On 2/27/18 9:44 AM, Chad Stansbury wrote:
> > We've been troubleshooting an issue where our web application is
> > getting a very occasional request that contains no cookies even
> > though a Wireshark on the application server shows those cookies
> > coming in on the request.
> >
> > I was able to replay the request that was captured via Wireshark,
> > and when doing so, everything goes through just fine... so that
> > rules out any sort of weird character set / header parsing issues.
> >
> > Environment specifics: Tomcat v7.0.77 running the (http-bio)
> > connector
> >
> > Now here's the twist: Currently something in the site
> > infrastructure has been configured to proxy to Tomcat with HTTP/1.0
> > instead of 1.1. We're trying to track that down and address that
> > issue (for performance reasons), but in the mean time, we're
> > wondering whether or not this is a concurrency issue related to
> > protocol caching/recycling?
> >
> > Has anyone ever seen anything like this before? Is there any
> > legitimate scenario(s) where Tomcat will *not* parse out the
> > cookies, but still route the request to the web app? Is this
> > possible an edge condition that that might be caused by the use of
> > HTTP/1.0? Could this possibly be caused by the number of maxThreads
> > exceeding the `processorCache` value?
>
> My immediate thought is that the cookie name or value contains a
> character that causes parsing to fail within Tomcat. Do you have any
> information about which cookies appear to be being ignored by Tomcat
> (that is, not passed-on to the application) versus those that ARE
> available to the application?
>
> Tomcat will generally log cookie-parsing errors to catalina.log, and
> possibly to the application's log as well, but it may only do so once
> per Tomcat-launch to avoid filling the disk with logs. Are you seeing
> anything in the Tomcat logs which suggest that cookie-parsing is failing
> ?
>
> Is the client a browser, or some non-human-interface device, such as a
> client-library or something like that?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVyfIACgkQHPApP6U8
> pFhh3BAAgq6+/VHzI6732NX6To6OVTvIwXw/8OB2A/jDLNwFgWfNrci/KmtSsH0w
> acYcA0D08WBsS8bHD+dHUQ2qvY+0ccyIVGCbyMpZk+du/4bsghpb3PIszSZ+Nsbm
> JNuYxeBVfNRxD2DIDT4+98N20rs5t1zX7mCyWzRT1OU31DRFgmfxkF6I0PTdTRSv
> gPzolgEtszgT7wePifE2tcn1/9J47MstEs6QGMOm9t/Q8naGMCI4DEumMeJZzH4L
> BmTXHVL69RTw8NWJ2Rhqy8jhF1ZLazl4ASE59nfXrCHa/EwNkZ6BaVS0pvqJlkQB
> fTZNvbFpx7m0NOaxGzS5m2KCKFtH1R279RnMHRHovy0ljAr4hlW26APlUhlJsYe7
> QMcm0/lyIZQd27pHhjoRzu9N5J01YotZ3rJLMzeBDI4vh1caRFtVAdyTHOdqdr+9
> 95WTTmtVRlcf7iq+9xdgIyPPCiFkdUOKFS0dc7V794yJjqOfW7ToJsEe/hZlCj5H
> 4yJGhJye3dH9rEzEgTPiIQb+mVYG9y5fJXK7XZ25pnvHNZ8+HheHXEUQdTWgW8ZI
> uHa6eitXXd0lp2xNUN2Itt58Isqn1U4cC7DsPZsH+eVSxIBrIUtx2YVDrwx7yywn
> 8K12ByKlxB7bpfBsMvmdhcZYuTp/y8q7W259117ZmCahhSwMm0k=
> =jwba
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*Chad Stansbury*
Pri

Re: Tomcat 7 - Sporadic problem re: cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chad,

On 2/27/18 9:44 AM, Chad Stansbury wrote:
> We've been troubleshooting an issue where our web application is
> getting a very occasional request that contains no cookies even
> though a Wireshark on the application server shows those cookies
> coming in on the request.
> 
> I was able to replay the request that was captured via Wireshark,
> and when doing so, everything goes through just fine... so that
> rules out any sort of weird character set / header parsing issues.
> 
> Environment specifics: Tomcat v7.0.77 running the (http-bio)
> connector
> 
> Now here's the twist: Currently something in the site
> infrastructure has been configured to proxy to Tomcat with HTTP/1.0
> instead of 1.1. We're trying to track that down and address that
> issue (for performance reasons), but in the mean time, we're
> wondering whether or not this is a concurrency issue related to
> protocol caching/recycling?
> 
> Has anyone ever seen anything like this before? Is there any
> legitimate scenario(s) where Tomcat will *not* parse out the
> cookies, but still route the request to the web app? Is this
> possible an edge condition that that might be caused by the use of
> HTTP/1.0? Could this possibly be caused by the number of maxThreads
> exceeding the `processorCache` value?

My immediate thought is that the cookie name or value contains a
character that causes parsing to fail within Tomcat. Do you have any
information about which cookies appear to be being ignored by Tomcat
(that is, not passed-on to the application) versus those that ARE
available to the application?

Tomcat will generally log cookie-parsing errors to catalina.log, and
possibly to the application's log as well, but it may only do so once
per Tomcat-launch to avoid filling the disk with logs. Are you seeing
anything in the Tomcat logs which suggest that cookie-parsing is failing
?

Is the client a browser, or some non-human-interface device, such as a
client-library or something like that?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVyfIACgkQHPApP6U8
pFhh3BAAgq6+/VHzI6732NX6To6OVTvIwXw/8OB2A/jDLNwFgWfNrci/KmtSsH0w
acYcA0D08WBsS8bHD+dHUQ2qvY+0ccyIVGCbyMpZk+du/4bsghpb3PIszSZ+Nsbm
JNuYxeBVfNRxD2DIDT4+98N20rs5t1zX7mCyWzRT1OU31DRFgmfxkF6I0PTdTRSv
gPzolgEtszgT7wePifE2tcn1/9J47MstEs6QGMOm9t/Q8naGMCI4DEumMeJZzH4L
BmTXHVL69RTw8NWJ2Rhqy8jhF1ZLazl4ASE59nfXrCHa/EwNkZ6BaVS0pvqJlkQB
fTZNvbFpx7m0NOaxGzS5m2KCKFtH1R279RnMHRHovy0ljAr4hlW26APlUhlJsYe7
QMcm0/lyIZQd27pHhjoRzu9N5J01YotZ3rJLMzeBDI4vh1caRFtVAdyTHOdqdr+9
95WTTmtVRlcf7iq+9xdgIyPPCiFkdUOKFS0dc7V794yJjqOfW7ToJsEe/hZlCj5H
4yJGhJye3dH9rEzEgTPiIQb+mVYG9y5fJXK7XZ25pnvHNZ8+HheHXEUQdTWgW8ZI
uHa6eitXXd0lp2xNUN2Itt58Isqn1U4cC7DsPZsH+eVSxIBrIUtx2YVDrwx7yywn
8K12ByKlxB7bpfBsMvmdhcZYuTp/y8q7W259117ZmCahhSwMm0k=
=jwba
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

We've been troubleshooting an issue where our web application is getting a
very occasional request that contains no cookies even though a Wireshark on
the application server shows those cookies coming in on the request.

I was able to replay the request that was captured via Wireshark, and when
doing so, everything goes through just fine... so that rules out any sort
of weird character set / header parsing issues.

Environment specifics: Tomcat v7.0.77 running the (http-bio) connector

Now here's the twist: Currently something in the site infrastructure has
been configured to proxy to Tomcat with HTTP/1.0 instead of 1.1. We're
trying to track that down and address that issue (for performance reasons),
but in the mean time, we're wondering whether or not this is a concurrency
issue related to protocol caching/recycling?

Has anyone ever seen anything like this before? Is there any legitimate
scenario(s) where Tomcat will *not* parse out the cookies, but still route
the request to the web app? Is this possible an edge condition that that
might be caused by the use of HTTP/1.0? Could this possibly be caused by
the number of maxThreads exceeding the `processorCache` value?

Thanks in advance, Chad

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Rémy Maucherat]

2016-11-10 16:02 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net
>:

> http://mrcoles.com/media/test/cookies-max-age-vs-expires.html
>
> Just tested with Edge and MSIE11 on Win 10. Both fail to recognize the
> expiration of a cookie when "expires" is not set and only max-age is set
> .
>
> Perhaps it behaves differently in "Trusted domains" or something like
> that.
>
> No idea about the domain. I went to test on Windows, and verified it
doesn't work without expires. So the link I posted had bad information, and
it's difficult to find something for IEs newer than 8.

Rémy

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 11/10/16 8:38 AM, Rémy Maucherat wrote:
> 2016-11-10 11:51 GMT+01:00 Mark Thomas <ma...@apache.org>:
> 
>> Tempting. But IE/Edge represents ~30% of the current browser
>> usage. If we were talking about a browser will a much smaller -
>> and shrinking - market share I could be convinced.
>> 
> 
> http://promincproductions.com/blog/set-cookie-expiration-date-browser-
compatiability/
>
> 
There's really conflicting info on this ...

http://mrcoles.com/media/test/cookies-max-age-vs-expires.html

Just tested with Edge and MSIE11 on Win 10. Both fail to recognize the
expiration of a cookie when "expires" is not set and only max-age is set
.

Perhaps it behaves differently in "Trusted domains" or something like
that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYJIwgAAoJEBzwKT+lPKRYbK8QALku/KtGcwQ3ezSxhoqYaZfV
XiHgCVgjZ+nujAb9aOvcrQCCkOkrmsXggOWmNm/c8m2g+Hfxh+mbFSuujsHvO9wa
k586b4mSZYo+uyzl2t3WRGOZ8tQTK7oGbUahlArrfUCGOt58VKb9Cn2yut9U8YV3
EmblFE81aeDZJ1HAurrj+0japBFqjyNCxYXXlC4v7IyE/a8tgAM77neTGbpC8br9
YPC5BajXnNVNlCGKfgc2LraBI9JH4rgxpulnyFL9aZhJsL8vpE94BGRRx6aXN2OM
3Kxysn/U8O5ODOlnbdGJpR8bUIRZHrfWxDyHWxQLLE8CVbhUgDZPQWeqo+y+SHpi
YueZ/4HYZna5SJxCDHC8rhMz1gdtw73a/DZ8aB7bQ5koXQNeyTA/4IYdiAUBkQs3
pL63HP4dO6AYUxyw1J71BF3zfAY6ydNGolgY/tc6YzQy7UW8BDaL/lurzOVPliq+
Vn9m+JvRN/I1AKJ7Stqp5Sb0eUfSpMVdDwZvNnJ+5p2q7K6C7jHxKMgjNDWksJme
9ioJumixJ15zqil3QjQAKuDhkx14xmCJFumS0No8IVwW2oUuLOF/dDUBPXv/q1FC
b/q9XLbFFe2Jks3Q3Pm7Mnu0BUJjQdm9qE8mof+OY7E94E+f1ys1QSiCHB5ZRjIi
bMICCb1Ox8JeYXJTTXLQ
=IcwU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Rémy Maucherat]

2016-11-10 11:51 GMT+01:00 Mark Thomas :

> Tempting. But IE/Edge represents ~30% of the current browser usage. If
> we were talking about a browser will a much smaller - and shrinking -
> market share I could be convinced.
>

http://promincproductions.com/blog/set-cookie-expiration-date-browser-compatiability/
There's really conflicting info on this ...

Rémy

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Mark Thomas]

On 07/11/2016 18:41, Rémy Maucherat wrote:
> 2016-11-05 23:58 GMT+01:00 Mark Thomas <ma...@apache.org>:
> 
>> On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote:
>>> Sorry if this has been already asked.   I searched the archives and
>>> didn't find what I was looking for.
>>
>> I don't recall anyone raising it before now.
>>
>>> Has anyone else run into an issue with persistent cookies in Tomcat
>>> 8.5+ and IE not working?
>>
>> I can confirm I see the same issue.
>>
>>> Does it make sense that the shipping configuration would not work
>>> with IE for persistent cookies?
>>
>> I'll turn that around. The shipping Tomcat configuration is RFC 6265
>> compliant. Does it make sense that Microsoft would ship multiple
>> versions of their browser for over a decade and fail to correctly
>> implement any of the cookie specifications that were considered current
>> throughout that period? (IE's cookie support is a sore point for me - I
>> have been dealing with IE's spec non-compliance for almost as long as I
>> have been working on Tomcat and it has always been unpleasant.)
>>
>> The default Tomcat community position in cases like this is that we do
>> not implement workarounds for bugs in third-party code. You need to
>> raise a bug with the provider of the buggy code.
>>
>> We do make exceptions and they are typically for IE. Part of me thinks
>> that if everyone refused to work-around Microsoft's poor implementations
>> of various standards (WebDAV is another area that comes to mind) a)
>> people would see just how bad some Microsoft code really is and b)
>> Microsoft might come under pressure to actually fix it.
>>
>> While we could make a stand on this particular point, I suspect that
>> Microsoft won't even notice and all it will do is make life difficult
>> for our users. As annoyed as I am with Microsoft about this, making life
>> difficult for Tomcat users is not what this community is about. As much
>> as it pains me to say it, I think we are going to have to work around this.
>>
>> Maybe an new option:
>> enableWorkaroundForBrokenMicrosoftCookieHandling
>>
>> Seriously, we need to decide if this needs to be configurable or not.
>> Given that RFC6265 allows both expires and max-age to be sent and the
>> the legacy processor sends both by default I'm currently leaning towards
>> just sending both in the RFC6265 processor.
>>
>> Assuming no-one objects, I'll aim to get this fixed for the next release
>> (not the one currently in progress but the one expected early next month).
>>
>> We also need to update the note in the docs about IE versions.
>>
> I don't understand, this is the same as the alwaysAddExpires field in
> LegacyCookieProcessor. IMO, it's a very good time to kill off IE support
> (HTTP/2, etc) in the default configuration,

Tempting. But IE/Edge represents ~30% of the current browser usage. If
we were talking about a browser will a much smaller - and shrinking -
market share I could be convinced.

> so it's not worth restoring
> this in your new cookie processor. If you do still want to restore it, it
> should use the same default value (based on the strict compliance flag).

It was configurable before because a strict reading of RFC2109 is that
it should not be there. RFC6265 allows both so there is no spec
compliance reason to not send it.

The only thing against not always sending it is the time taken to
compute it and the bytes required to send it. However, given the number
of end users this is likely to impact, I don't see much point in making
it optional (it will only get sent on cookie creation/update and then
only if max age is set).

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Rémy Maucherat]

2016-11-05 23:58 GMT+01:00 Mark Thomas <ma...@apache.org>:

> On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote:
> > Sorry if this has been already asked.   I searched the archives and
> > didn't find what I was looking for.
>
> I don't recall anyone raising it before now.
>
> > Has anyone else run into an issue with persistent cookies in Tomcat
> > 8.5+ and IE not working?
>
> I can confirm I see the same issue.
>
> > Does it make sense that the shipping configuration would not work
> > with IE for persistent cookies?
>
> I'll turn that around. The shipping Tomcat configuration is RFC 6265
> compliant. Does it make sense that Microsoft would ship multiple
> versions of their browser for over a decade and fail to correctly
> implement any of the cookie specifications that were considered current
> throughout that period? (IE's cookie support is a sore point for me - I
> have been dealing with IE's spec non-compliance for almost as long as I
> have been working on Tomcat and it has always been unpleasant.)
>
> The default Tomcat community position in cases like this is that we do
> not implement workarounds for bugs in third-party code. You need to
> raise a bug with the provider of the buggy code.
>
> We do make exceptions and they are typically for IE. Part of me thinks
> that if everyone refused to work-around Microsoft's poor implementations
> of various standards (WebDAV is another area that comes to mind) a)
> people would see just how bad some Microsoft code really is and b)
> Microsoft might come under pressure to actually fix it.
>
> While we could make a stand on this particular point, I suspect that
> Microsoft won't even notice and all it will do is make life difficult
> for our users. As annoyed as I am with Microsoft about this, making life
> difficult for Tomcat users is not what this community is about. As much
> as it pains me to say it, I think we are going to have to work around this.
>
> Maybe an new option:
> enableWorkaroundForBrokenMicrosoftCookieHandling
>
> Seriously, we need to decide if this needs to be configurable or not.
> Given that RFC6265 allows both expires and max-age to be sent and the
> the legacy processor sends both by default I'm currently leaning towards
> just sending both in the RFC6265 processor.
>
> Assuming no-one objects, I'll aim to get this fixed for the next release
> (not the one currently in progress but the one expected early next month).
>
> We also need to update the note in the docs about IE versions.
>
> I don't understand, this is the same as the alwaysAddExpires field in
LegacyCookieProcessor. IMO, it's a very good time to kill off IE support
(HTTP/2, etc) in the default configuration, so it's not worth restoring
this in your new cookie processor. If you do still want to restore it, it
should use the same default value (based on the strict compliance flag).

Rémy

RE: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Hedrick, Brooke - 43]

Thanks Mark and everyone else.  I appreciate all of the sentiments.  It is very 
annoying that MS can't get on the bus for something like this, even in Edge.  
But as you said IE remains the default corporate browser on Windows.

I appreciate your working on this.


Brooke Hedrick

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, November 07, 2016 9:25 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent 
cookies for all IE versions

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Stefan,

On 11/6/16 4:31 AM, Stefan Mayr wrote:
> Am 05.11.2016 um 23:58 schrieb Mark Thomas:
>> While we could make a stand on this particular point, I suspect that 
>> Microsoft won't even notice and all it will do is make life difficult 
>> for our users. As annoyed as I am with Microsoft about this, making 
>> life difficult for Tomcat users is not what this community is about. 
>> As much as it pains me to say it, I think we are going to have to 
>> work around this.
>> 
>> Maybe an new option: 
>> enableWorkaroundForBrokenMicrosoftCookieHandling
>> 
>> Seriously, we need to decide if this needs to be configurable or not. 
>> Given that RFC6265 allows both expires and max-age to be sent and the 
>> the legacy processor sends both by default I'm currently leaning 
>> towards just sending both in the RFC6265 processor.
> 
> +1 sending both headers
> 
> Assume the following: people upgrade Tomcat and the app stops working 
> in IE (most corporate users default browser). They will blame Tomcat - 
> not IE. Why should we risk to damage Tomcats reputation if sending 
> both headers is still standards compliant?
> This "hack" seems quite acceptable for me. Adding a configuration 
> option for a "strict" mode would make it easier to test future browser 
> implementations with real applications.

I'm +1 on adding an option, and I think it should be enabled *by default*. The 
name of the option should be more clear about what it actually does rather than 
"fix cookies for stupid MSIE" (as satisfying as that would be).

It should be something more like supplyExpiresAndMaxAgeWithCookies.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYIJzaAAoJEBzwKT+lPKRYPHAQAL/zTmi/A4wdWUVoWZlSM+Jd
jrxpewT/a2QmhFChpTworCYGk8U4qkfPwuCuh8SEc91+5e8RuUiUQH+HAmnzjaHc
f/h40HJIE3EFdKQVt5+QLagrD0XTlt/p+AjmlyEVVlTDAGqx67JX9NaFjvRe0GD+
7i3BgBJeuw9Mo4rAVZmOtTkW1njR+1I066Bq1X8+fK48u7Btq4rJgOjiVmNTjPax
HhemAPtg/rgaNFCM/TmWdCj1XfmVHHlwwoWxbvn+fPO2IXBJccNBscxZBjaeOvuD
lXjzvsHxeWMxa9JkqgwBxQQNeE2PZNd5od5nbayhhpehhqAMEjKlKhPGx/SHZno9
thNxvhQ+3x0u7JzZMgZi2dVsmZSa7vWAiGLdJHWzpiyQI7m9vwYMMlr/d8s5irXi
NR6nhf/dyjEKbSNqEqEKH+oJHblkEedcKn5vaLMKFTpD1dT5itvslGum3PdyJgAj
647qnxJnkhRJkZ5zxwO1KHSIQjcQRZHrKsWMWsuh2rJbchwvvi9q7Ts/uBc+nRO6
idfWUr5SqLaC7a/HA9zq7jeJwfqAWyu3fC2ZZFMctKq7K6+Ebf8wH4PhUD5vov8O
3GfOh2im+6IrAepMDCZJxcSgFRRi+Xbsd+kaw8YLQh2utCkrgBjmvkKxOrSIfcVq
PFQuAUNv3sDqmEPsJuKv
=kL5K
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Stefan,

On 11/6/16 4:31 AM, Stefan Mayr wrote:
> Am 05.11.2016 um 23:58 schrieb Mark Thomas:
>> While we could make a stand on this particular point, I suspect
>> that Microsoft won't even notice and all it will do is make life
>> difficult for our users. As annoyed as I am with Microsoft about
>> this, making life difficult for Tomcat users is not what this
>> community is about. As much as it pains me to say it, I think we
>> are going to have to work around this.
>> 
>> Maybe an new option: 
>> enableWorkaroundForBrokenMicrosoftCookieHandling
>> 
>> Seriously, we need to decide if this needs to be configurable or
>> not. Given that RFC6265 allows both expires and max-age to be
>> sent and the the legacy processor sends both by default I'm
>> currently leaning towards just sending both in the RFC6265
>> processor.
> 
> +1 sending both headers
> 
> Assume the following: people upgrade Tomcat and the app stops
> working in IE (most corporate users default browser). They will
> blame Tomcat - not IE. Why should we risk to damage Tomcats
> reputation if sending both headers is still standards compliant?
> This "hack" seems quite acceptable for me. Adding a configuration
> option for a "strict" mode would make it easier to test future
> browser implementations with real applications.

I'm +1 on adding an option, and I think it should be enabled *by
default*. The name of the option should be more clear about what it
actually does rather than "fix cookies for stupid MSIE" (as satisfying
as that would be).

It should be something more like supplyExpiresAndMaxAgeWithCookies.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYIJzaAAoJEBzwKT+lPKRYPHAQAL/zTmi/A4wdWUVoWZlSM+Jd
jrxpewT/a2QmhFChpTworCYGk8U4qkfPwuCuh8SEc91+5e8RuUiUQH+HAmnzjaHc
f/h40HJIE3EFdKQVt5+QLagrD0XTlt/p+AjmlyEVVlTDAGqx67JX9NaFjvRe0GD+
7i3BgBJeuw9Mo4rAVZmOtTkW1njR+1I066Bq1X8+fK48u7Btq4rJgOjiVmNTjPax
HhemAPtg/rgaNFCM/TmWdCj1XfmVHHlwwoWxbvn+fPO2IXBJccNBscxZBjaeOvuD
lXjzvsHxeWMxa9JkqgwBxQQNeE2PZNd5od5nbayhhpehhqAMEjKlKhPGx/SHZno9
thNxvhQ+3x0u7JzZMgZi2dVsmZSa7vWAiGLdJHWzpiyQI7m9vwYMMlr/d8s5irXi
NR6nhf/dyjEKbSNqEqEKH+oJHblkEedcKn5vaLMKFTpD1dT5itvslGum3PdyJgAj
647qnxJnkhRJkZ5zxwO1KHSIQjcQRZHrKsWMWsuh2rJbchwvvi9q7Ts/uBc+nRO6
idfWUr5SqLaC7a/HA9zq7jeJwfqAWyu3fC2ZZFMctKq7K6+Ebf8wH4PhUD5vov8O
3GfOh2im+6IrAepMDCZJxcSgFRRi+Xbsd+kaw8YLQh2utCkrgBjmvkKxOrSIfcVq
PFQuAUNv3sDqmEPsJuKv
=kL5K
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Stefan Mayr]

Am 05.11.2016 um 23:58 schrieb Mark Thomas:
> On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote:
>> Sorry if this has been already asked.   I searched the archives and
>> didn't find what I was looking for.
> 
> I don't recall anyone raising it before now.
> 
>> Has anyone else run into an issue with persistent cookies in Tomcat
>> 8.5+ and IE not working?
> 
> I can confirm I see the same issue.
> 
>> Does it make sense that the shipping configuration would not work
>> with IE for persistent cookies?
> 
> I'll turn that around. The shipping Tomcat configuration is RFC 6265
> compliant. Does it make sense that Microsoft would ship multiple
> versions of their browser for over a decade and fail to correctly
> implement any of the cookie specifications that were considered current
> throughout that period? (IE's cookie support is a sore point for me - I
> have been dealing with IE's spec non-compliance for almost as long as I
> have been working on Tomcat and it has always been unpleasant.)

When I read
https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/
and the last response to
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8183708/
from the Microsoft Edge Team I fear full RFC6265 support is still some
years away in Microsoft world

> The default Tomcat community position in cases like this is that we do
> not implement workarounds for bugs in third-party code. You need to
> raise a bug with the provider of the buggy code.
> 
> We do make exceptions and they are typically for IE. Part of me thinks
> that if everyone refused to work-around Microsoft's poor implementations
> of various standards (WebDAV is another area that comes to mind) a)
> people would see just how bad some Microsoft code really is and b)
> Microsoft might come under pressure to actually fix it.
> 
> While we could make a stand on this particular point, I suspect that
> Microsoft won't even notice and all it will do is make life difficult
> for our users. As annoyed as I am with Microsoft about this, making life
> difficult for Tomcat users is not what this community is about. As much
> as it pains me to say it, I think we are going to have to work around this.
> 
> Maybe an new option:
> enableWorkaroundForBrokenMicrosoftCookieHandling
> 
> Seriously, we need to decide if this needs to be configurable or not.
> Given that RFC6265 allows both expires and max-age to be sent and the
> the legacy processor sends both by default I'm currently leaning towards
> just sending both in the RFC6265 processor.

+1 sending both headers

Assume the following: people upgrade Tomcat and the app stops working in
IE (most corporate users default browser). They will blame Tomcat - not
IE. Why should we risk to damage Tomcats reputation if sending both
headers is still standards compliant? This "hack" seems quite acceptable
for me. Adding a configuration option for a "strict" mode would make it
easier to test future browser implementations with real applications.

> Assuming no-one objects, I'll aim to get this fixed for the next release
> (not the one currently in progress but the one expected early next month).
> 
> We also need to update the note in the docs about IE versions.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 

Stefan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Mark Thomas]

On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote:
> Sorry if this has been already asked.   I searched the archives and
> didn't find what I was looking for.

I don't recall anyone raising it before now.

> Has anyone else run into an issue with persistent cookies in Tomcat
> 8.5+ and IE not working?

I can confirm I see the same issue.

> Does it make sense that the shipping configuration would not work
> with IE for persistent cookies?

I'll turn that around. The shipping Tomcat configuration is RFC 6265
compliant. Does it make sense that Microsoft would ship multiple
versions of their browser for over a decade and fail to correctly
implement any of the cookie specifications that were considered current
throughout that period? (IE's cookie support is a sore point for me - I
have been dealing with IE's spec non-compliance for almost as long as I
have been working on Tomcat and it has always been unpleasant.)

The default Tomcat community position in cases like this is that we do
not implement workarounds for bugs in third-party code. You need to
raise a bug with the provider of the buggy code.

We do make exceptions and they are typically for IE. Part of me thinks
that if everyone refused to work-around Microsoft's poor implementations
of various standards (WebDAV is another area that comes to mind) a)
people would see just how bad some Microsoft code really is and b)
Microsoft might come under pressure to actually fix it.

While we could make a stand on this particular point, I suspect that
Microsoft won't even notice and all it will do is make life difficult
for our users. As annoyed as I am with Microsoft about this, making life
difficult for Tomcat users is not what this community is about. As much
as it pains me to say it, I think we are going to have to work around this.

Maybe an new option:
enableWorkaroundForBrokenMicrosoftCookieHandling

Seriously, we need to decide if this needs to be configurable or not.
Given that RFC6265 allows both expires and max-age to be sent and the
the legacy processor sends both by default I'm currently leaning towards
just sending both in the RFC6265 processor.

Assuming no-one objects, I'll aim to get this fixed for the next release
(not the one currently in progress but the one expected early next month).

We also need to update the note in the docs about IE versions.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Hedrick, Brooke - 43]

Sorry if this has been already asked.   I searched the archives and didn't find 
what I was looking for.

Has anyone else run into an issue with persistent cookies in Tomcat 8.5+ and IE 
not working?

We are seeing an issue where the new default cookie processor, 
org.apache.tomcat.util.http.Rfc6265CookieProcessor, is not writing out the 
expires tag for the cookies.  It is only writing out max-age in the 
generateHeader() method.  This is a change from the previous cookie processing.

Here's the current code:
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java

There is documentation at 
https://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html which 
explains the new vs legacy cookie handler and that this behavior is 
intentional.  It doesn't explain that this behavior isn't limited to IE6-7.  It 
also affects IE8-11 and Edge and as a result, by default, Tomcat 8.5+ does not 
create persistent cookies that work with IE on any IE version.

Does it make sense that the shipping configuration would not work with IE for 
persistent cookies?



There are other gotchas like blank/null cookie values cause problems with the 
new default processor and a leading period in the cookie domain causes issues.  
We have fixed these issues across many applications, but weren't expecting 
issues with persistent cookies not working at all in IE.  The documentation on 
the Tomcat page alludes to IE6-7 having the issue.  It doesn't mention the 
other versions.

We are looking into short term solutions (while avoiding the legacy cookie 
processor ) - writing our own headers, creating a filter, ...

Another interesting observation is that the ExpiresFilter included with Tomcat 
still writes both the expires and max-age attributes.  
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/filters/ExpiresFilter.html

Here's a page where you can see the issue of IE not reading the max-age 
attribute.  On Chrome, FF, and Safari, the test will complete after a few runs. 
 On IE, it runs indefinitely.
http://mrcoles.com/media/test/cookies-max-age-vs-expires.html

If I have missed some configuration, tested incorrectly, etc., please let me 
know.

Re: Webapp with underscore in it's name leads to failed session-cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/22/16 6:58 AM, Mark Thomas wrote:
> On 22/06/2016 11:29, Mark Thomas wrote:
>> On 22/06/2016 09:28, Markus Näher wrote:
> 
>>> In the web console of firefox, I could see that the session
>>> cookie was set with the path /jsf%5ftest, while other cookies
>>> (set by myfaces) were correctly set with the path /jsf_test. It
>>> looks like firefox treats /jsf_test and /jsf%5ftest as
>>> different pathes and therefore does not send the session cookie
>>> with the next request, while chromium ignores the difference.
>> 
>> I see a similar issue if I rename the examples web application
>> to "exa_mples". It shouldn't take me too long to figure out where
>> things are going wrong.
> 
> Tomcat is correctly setting the path for the session cookie as
> "/exa_mples"
> 
>> I'll keep that in mind once I figure out the root cause. It may
>> impact how we fix this.
> 
> The problem is that FireFox, by default, encodes all URIs and
> doesn't take account of the encoding when matching URIs to cookie
> paths. Failing to account for encoding looks like a FireFox bug to
> me.
> 
> A possible work-around is to disable the automatic encoding of URLs
> that FireFox provides by setting network.standard-url.encode-utf8
> to false under about:config.
> 
>>> Unfortunately, my real-world productive project has an
>>> underscore in it's name too, but as many users have bookmarked
>>> it, I can't just rename it.
>>> 
>>> Is this a bug in tomcat ?
>> 
>> At this point I'd say it is likely but until I dig into this to
>> figure out exactly what the root cause is, I can't be sure.
> 
> No, it is a FireFox bug. And a long standing one at that. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=665851

Something doesn't smell right, here.

I've been using Mozilla Firefox and Tomcat together for ... ever and
my primary web application used for development is called
"cschultz-[product]" (note the hyphen). I have never ever had any
issues with that hyphen bring broken anywhere along the way. (I'm not
sure I've tried an underscore... I could try that). Here are my
relevant settings from about:config:

network.standard-url.encode-utf8;true
network.standard-url.escape-utf8;true

Does this only effect underscores?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXbVAvAAoJEBzwKT+lPKRYcC4QAJ9vK+NvkJCTDKfW80BaLZSO
j7jXWgbMf9rOTGfV7BSD+seBcId2ixJjOjod2yNJJ21d83BXbdPFGP96staRTt3v
8TOB/42WBIlfMt+CHvI/ltVBUsQ644so55qy6HrQcBO9yjVJiy3mzyJMTjAjLGZW
nGvnZm4enUGqPqiPgY26TRxOR9toNpH9mq4qHQdSM+vesLnB7t0C2pNt0v5Wj3Og
Nr6g8GIWN0czA8eClUp8I4PQP/ZCEs5o8lbkBo9MCmz7H0uijEIfI7R0uDE2ptWy
pZ8N7a4kv/8LHZdShGQJ/RSUDVTb3dbaI2rfpOfKmKEVmt3LSEgHNb6N+DB64KLW
qMXhiKqiSqi2UUOgOZvbBmfpcDFPEd7uYTnHzXjojeOsKxF5jtVxpgEGrWTcTY9t
F3BdVk5PuYUZTAI3fpOT5CuAHfZ8hThi7ouWiIjo9LlYBq8senEXteXwTvZnfJGc
rsOq7ADHQX1T7MQjrH7qqIfSeXb0ekaucRubp2uXH6WSZ7kbGmssUc5M/ZTEOcWu
NJr+XXHKyp7+8ubBgTWZLRVnl1ZrMLAQMklIEj3TbURYUlSQTKDLkwGHHDyFNZck
mamDfoiu/zSbOn6ocuoDBm0UXfK24FDbf/Ega7Y7V+ChFuKPLKdf8pUNPGkuqBmA
Q8lPLYh11HWvayvXTP50
=TobU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp with underscore in it's name leads to failed session-cookies

[Mark Thomas]

On 22/06/2016 11:29, Mark Thomas wrote:
> On 22/06/2016 09:28, Markus Näher wrote:

>> In the web console of firefox, I could see that the session cookie was
>> set with the path /jsf%5ftest, while other cookies (set by myfaces) were
>> correctly set with the path /jsf_test.
>> It looks like firefox treats /jsf_test and /jsf%5ftest as different
>> pathes and therefore does not send the session cookie with the next
>> request, while chromium ignores the difference.
> 
> I see a similar issue if I rename the examples web application to
> "exa_mples". It shouldn't take me too long to figure out where things
> are going wrong.

Tomcat is correctly setting the path for the session cookie as "/exa_mples"

> I'll keep that in mind once I figure out the root cause. It may impact
> how we fix this.

The problem is that FireFox, by default, encodes all URIs and doesn't
take account of the encoding when matching URIs to cookie paths. Failing
to account for encoding looks like a FireFox bug to me.

A possible work-around is to disable the automatic encoding of URLs that
FireFox provides by setting network.standard-url.encode-utf8 to false
under about:config.

>> Unfortunately, my real-world productive project has an underscore in
>> it's name too, but as many users have bookmarked it, I can't just rename
>> it.
>>
>> Is this a bug in tomcat ?
> 
> At this point I'd say it is likely but until I dig into this to figure
> out exactly what the root cause is, I can't be sure.

No, it is a FireFox bug. And a long standing one at that.
https://bugzilla.mozilla.org/show_bug.cgi?id=665851

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp with underscore in it's name leads to failed session-cookies

[Mark Thomas]

On 22/06/2016 09:28, Markus Näher wrote:
> Hi,
> 
> I'm working on a JSF (myfaces) project that runs on Tomcat. First I
> thought it was a myfaces issue, but they told me that the container is
> responsible for the session cookie, so now I'm here :-)

That is correct. To a point. There are some things the application can
do to control the session cookie so the problem may lie elsewhere but,
with the information provided to date, you look to be asking in the
right place.

> I've created a minimal JSF test project and I called it jsf_test. When I
> open the tomcat manager (web) and the webapp's welcome page in the
> browser, I can see that every reload of the webapp page increases the
> session count.

If you have a test case it is generally a good idea to put it somewhere
where the members of the mailing list can access it.

> In the web console of firefox, I could see that the session cookie was
> set with the path /jsf%5ftest, while other cookies (set by myfaces) were
> correctly set with the path /jsf_test.
> It looks like firefox treats /jsf_test and /jsf%5ftest as different
> pathes and therefore does not send the session cookie with the next
> request, while chromium ignores the difference.

I see a similar issue if I rename the examples web application to
"exa_mples". It shouldn't take me too long to figure out where things
are going wrong.

> I also noticed that the issue does not occur on every deployment /
> tomcat restart. It looks like the webapp name is stored internally
> during initialization, and depending on little timing variations (race
> condition ?), it is either initialized to the escaped or the unescaped
> value. Tomcat manager always displays the unescaped name.

That is very strange. Web application initialisation is single threaded
(per webapp) so a race condition is unlikely.

> Among my teammates, some are always affected, some occasionally, and
> some never.

That suggests something triggered by the environment. No idea what it
could be at this point though.

> After renaming the webapp to "jsftest", the session count increments
> were gone.
> The issue also occurs with a minus in the name, like "jsf-test".

I'll keep that in mind once I figure out the root cause. It may impact
how we fix this.

> Unfortunately, my real-world productive project has an underscore in
> it's name too, but as many users have bookmarked it, I can't just rename
> it.
> 
> Is this a bug in tomcat ?

At this point I'd say it is likely but until I dig into this to figure
out exactly what the root cause is, I can't be sure.

> Environment:
> OS: Linux / Windows
> Tomcat version: 8.0.36
> JDK: Oracle JDK 1.8.0_92
> Within the team, we're using different minor verions, but I've tested
> with the newest ones.

Thanks for providing the version info. Not everyone does and it can
often be very helpful.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Webapp with underscore in it's name leads to failed session-cookies

[Markus Näher]

Hi,

I'm working on a JSF (myfaces) project that runs on Tomcat. First I thought it was a myfaces issue, 
but they told me that the container is responsible for the session cookie, so now I'm here :-)


I've created a minimal JSF test project and I called it jsf_test. When I open the tomcat manager (web) 
and the webapp's welcome page in the browser, I can see that every reload of the webapp page increases 
the session count.


In the web console of firefox, I could see that the session cookie was set with the path /jsf%5ftest, 
while other cookies (set by myfaces) were correctly set with the path /jsf_test.
It looks like firefox treats /jsf_test and /jsf%5ftest as different pathes and therefore does not send 
the session cookie with the next request, while chromium ignores the difference.


I also noticed that the issue does not occur on every deployment / tomcat restart. It looks like the 
webapp name is stored internally during initialization, and depending on little timing variations 
(race condition ?), it is either initialized to the escaped or the unescaped value. Tomcat manager 
always displays the unescaped name.


Among my teammates, some are always affected, some occasionally, and some never.

After renaming the webapp to "jsftest", the session count increments were gone.
The issue also occurs with a minus in the name, like "jsf-test".

Unfortunately, my real-world productive project has an underscore in it's name too, but as many users 
have bookmarked it, I can't just rename it.


Is this a bug in tomcat ?

Environment:
OS: Linux / Windows
Tomcat version: 8.0.36
JDK: Oracle JDK 1.8.0_92
Within the team, we're using different minor verions, but I've tested with the 
newest ones.

Regards,
Markus Näher

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeff,

On 9/11/15 10:09 AM, Jeffrey Janner wrote:
>> -Original Message- From: Christopher Schultz
>> [mailto:ch...@christopherschultz.net] Sent: Thursday, September
>> 10, 2015 2:24 PM To: Tomcat Users List <users@tomcat.apache.org> 
>> Subject: Re: Multiple JSESSIONID cookies being presented.
>> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Jeffrey,
>> 
>> On 9/10/15 12:26 PM, Jeffrey Janner wrote:
>>> Thanks for all the help guys. I think I've sussed out what is 
>>> going on here.  Now just have to get the Dev guys to address
>>> it.
>>> 
>>> After spending a good bit of time clearing and watching
>>> cookies and access logs, both with and without a favicon.ico
>>> file, I found that the doubling was happening only if the file
>>> was missing.  I checked the error.jsp file and it does have
>>> session=true set, and if the icon file is missing, the
>>> error.jsp is definitely being sent.
>>> 
>>> So it looks like the possible solutions are: 1) provide a 
>>> favicon.ico file.
>> 
>> This fixes the symptom, not the problem. You'll get the same
>> problem with clients who request /apple-touch-icon.png,
>> /robots.txt, or just about any other file that ends up resulting
>> in a 404. This could be something from within the application
>> itself, and will (apparently) cause mass confusion.
>> 
>>> 2) remove the session=true setting from the error page.
>> 
>> This is the right answer. Do you really need the session in
>> error.jsp?
>> 
>>> 3) somehow not send the error.jsp when a sub-link (image,
>>> script, etc.) results in a 404.
>>> 
>>> 4) Have the login page of APP2 provide it's own icon  
>>> directive (it doesn't currently have one.)
>> 
>>> Any other options?
>> 
>> If you absolutely need access to the session in your error.jsp
>> file, you can do this:
>> 
>>  <% HttpSession session =
>> request.getSession(false);
>> 
>> ... %>
>> 
>> This will prevent sessions from being created when there isn't
>> already a session. You'll have to check the code for error.jsp to
>> make sure that no code uses the session before checking it for
>> null -- because session="true" guarantees that the "session"
>> reference will be non-null.
>> 
>> That will allow you to use session information in error.jsp if a 
>> session already exists, but not create a superfluous session when
>> one does not (yet) exist.
>> 
> Thanks for the above Chris. I passed the information on to someone
> who can get it implemented.
> 
>> Back to Tomcat's session management: Tomcat *can* handle this 
>> situation properly: it will try all JSESSIONID cookies it gets to
>> find a valid one in the current web application. So, multiple
>> JSESSIONID cookies won't confuse Tomcat. Some other component
>> must be mis-understanding the session identifier in some way.
>> 
>> - -chris
> 
> Yes, I don't think it's bothering Tomcat at all. We've never
> experienced a problem with direct-to-tomcat configurations, and
> we've had this setup for years. We recently implemented an HaProxy
> front-end using stick-tables and think it's potentially confusing
> HaProxy. But I can't swear to that, because I did find a problem
> with how jvmRoute was being applied, resulting in both servers
> providing the same value, so that could have been the underlying
> problem all along. However, the session on error is a basics issue
> that needs to be resolved. Thanks again.  I think we are done
> here.

I think I missed that part about switching to HAProxy. If you are
using sticky sessions, HAProxy needs to know that session X was
replaced by session Y. That ought to happen because Tomcat will be
sending Set-Cookie response headers, and HAProxy ought to pick-up on
it, but it's possible something is getting confused during the scuffle.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8z/cAAoJEBzwKT+lPKRYLnkP/icNKczwo6lNH+mCd4mMnTUn
9Lsgz+sRDxjE4d8+ccKlv1cYi+ava0zEAQWgKgeWcxaBGO9NvUyTiXy6CIQKMBNW
dNYQBreU2aVDlFAuLHPzCGSjSRpt9RFC15tCrAqCFKXcQF8S3pkYtzEWgwXVB1mH
5GRpkqyMj+4HDPDUVQXxu5NBUPuu7p2JZroMtXeo0Na1P6AXpmer0/KOqR0EYDwD
oGYMKtRWcZcXeYpUJNi1PlWYLl753N1tJL5j1rwXUJKOG25mekhf3tX9V4EjALOp
LvA1/GSD5OQMEBfzBXEIjT5dmRJMwi1mkPGwzFtS9FN0dVCdhjofCIdnPLTCGXy8
R9dHIcql3EEcq2zulW4Ai6e7rm57CkwEPzuwT1p+pjVkH0fj7zaZJhjcZaKzFoRc
fkwA/9Q3P6l/f6xkjeI07kXtY8MqdHLWK/nIISs1F4vbJfKQ5Ki0Aw1jJwgzn/1O
ITFWRk5WW5IJsXkoItFUBMbkqsNNi319rg64XJFS9Dt8oKRaw+ENwKPOZVSCZ05n
l9nxtj8kiqGNaigG7WcAfQSsx8JUbRvpt44yTI6zl7zLav+Dcig5DKeHpztfvxDb
aumO17zH2KwUh2zfdl7zFr6mc7AYYkaQb/1lpM4ehvsvXIStj45J00tzvkKLrYwp
M6N24e0Oia9aBzmLoiVc
=egHr
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
> Sent: Thursday, September 10, 2015 12:01 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> > Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > I checked the error.jsp file and it does have session=true set, and if
> the icon file
> > is missing, the error.jsp is definitely being sent.
> 
> > So it looks like the possible solutions are:
> > 1) provide a favicon.ico file.
> > 2) remove the session=true setting from the error page.
> > 3) somehow not send the error.jsp when a sub-link (image, script,
> etc.) results in a 404.
> > 4) Have the login page of APP2 provide it's own icon  directive
> (it doesn't currently
> > have one.)
> 
> Why would you ever want your error.jsp to create a session?  Sounds like
> an easy DoS attack to me.
> 
>  - Chuck
> 
Programmers.  What more do I need to say


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, September 10, 2015 2:24 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/10/15 12:26 PM, Jeffrey Janner wrote:
> > Thanks for all the help guys. I think I've sussed out what is
> > going on here.  Now just have to get the Dev guys to address it.
> >
> > After spending a good bit of time clearing and watching cookies
> > and access logs, both with and without a favicon.ico file, I found
> > that the doubling was happening only if the file was missing.  I
> > checked the error.jsp file and it does have session=true set, and
> > if the icon file is missing, the error.jsp is definitely being
> > sent.
> >
> > So it looks like the possible solutions are: 1) provide a
> > favicon.ico file.
> 
> This fixes the symptom, not the problem. You'll get the same problem
> with clients who request /apple-touch-icon.png, /robots.txt, or just
> about any other file that ends up resulting in a 404. This could be
> something from within the application itself, and will (apparently)
> cause mass confusion.
> 
> > 2) remove the session=true setting from the error page.
> 
> This is the right answer. Do you really need the session in error.jsp?
> 
> > 3) somehow not send the error.jsp when a sub-link (image, script,
> > etc.) results in a 404.
> >
> > 4) Have the login page of APP2 provide it's own icon 
> > directive (it doesn't currently have one.)
> 
> > Any other options?
> 
> If you absolutely need access to the session in your error.jsp file,
> you can do this:
> 
> 
> <%
>   HttpSession session = request.getSession(false);
> 
>   ...
> %>
> 
> This will prevent sessions from being created when there isn't already
> a session. You'll have to check the code for error.jsp to make sure
> that no code uses the session before checking it for null -- because
> session="true" guarantees that the "session" reference will be non-null.
> 
> That will allow you to use session information in error.jsp if a
> session already exists, but not create a superfluous session when one
> does not (yet) exist.
> 
Thanks for the above Chris. I passed the information on to someone who can get 
it implemented.

> Back to Tomcat's session management: Tomcat *can* handle this
> situation properly: it will try all JSESSIONID cookies it gets to find
> a valid one in the current web application. So, multiple JSESSIONID
> cookies won't confuse Tomcat. Some other component must be
> mis-understanding the session identifier in some way.
> 
> - -chris

Yes, I don't think it's bothering Tomcat at all. We've never experienced a 
problem with direct-to-tomcat configurations, and we've had this setup for 
years.
We recently implemented an HaProxy front-end using stick-tables and think it's 
potentially confusing HaProxy. But I can't swear to that, because I did find a 
problem with how jvmRoute was being applied, resulting in both servers 
providing the same value, so that could have been the underlying problem all 
along.
However, the session on error is a basics issue that needs to be resolved.
Thanks again.  I think we are done here.
Jeff

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, September 09, 2015 1:50 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/9/15 12:08 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Caldarale, Charles R
> >> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08,
> >> 2015 4:58 PM To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: RE: Multiple JSESSIONID cookies being presented.
> >>
> >>> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> >>> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >>>> Thanks for the clarification of what's supposed to happen on
> >> receipt, Jose.
> >>>> However, I am describing what happens on first contact from
> >>>> the
> >> client to the server.
> >>>> The browser sends https://hostname/APP2, and Tomcat returns:
> >>>> JSESSIONID=, path=/and   JSESSIONID=,
> >>>> path=/APP2/
> >>
> >>> Indeed, it doesn't make sense for me to return different id (
> >>>  ,  ) if you are accesing to only one context (/APP2)
> >>
> >>> Are you sure that your webapp deployed in /APP2 is not accesing
> >>> to resources ( session-aware resources as JSP, servlet, .. .I
> >>> mean) stored in ROOT context ?
> >>
> >> As I think someone previously mentioned, the client (browser) may
> >> well be sending an unsolicited request to the default webapp,
> >> such as when trying to retrieve favicon.ico.  You might want to
> >> run Fiddler or Wireshark on the client to see exactly what's
> >> being sent to the server.
> >>
> >
> > And there's no way to keep a browser from asking for the
> > favicon.ico file from the root. We don't have one, so I would
> > expect a 404 is sent, which looking at the access log file is what
> > happens. However, is this the issue?  I tested this doing a manual
> > https://hostname/favicon.ico and see that we also return our root
> > app's error page. We also seem to be doing that for the
> > auto-generated request, judging by the bytes returned value, even
> > though it won't get displayed. And I bet that the error page is
> > setting the session cookie for some reason. Does that sound
> > reasonable? Is my solution just providing a favicon.ico file?
> 
> Can you make sure that all cookies have been cleared from the test
> client and then explain exactly when Tomcat sends the Set-Cookie headers
> ?
> 
> When we had this problem, it was usually because the client had old
> funky session ids in its cookie jar and the solution was to blow them
> all away and start-over fresh. (Then fix our software so it wouldn't
> happen anymore.)
> 
> - -chris
Thanks for all the help guys. I think I've sussed out what is going on here.  
Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies and access 
logs, both with and without a favicon.ico file, I found that the doubling was 
happening only if the file was missing.  I checked the error.jsp file and it 
does have session=true set, and if the icon file is missing, the error.jsp is 
definitely being sent.
So it looks like the possible solutions are:
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results 
in a 404.
4) Have the login page of APP2 provide it's own icon  directive (it 
doesn't currently have one.)

Any other options?
Jeff

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Caldarale, Charles R]

> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] 
> Subject: RE: Multiple JSESSIONID cookies being presented.

> I checked the error.jsp file and it does have session=true set, and if the 
> icon file 
> is missing, the error.jsp is definitely being sent.

> So it looks like the possible solutions are:
> 1) provide a favicon.ico file.
> 2) remove the session=true setting from the error page.
> 3) somehow not send the error.jsp when a sub-link (image, script, etc.) 
> results in a 404.
> 4) Have the login page of APP2 provide it's own icon  directive (it 
> doesn't currently 
> have one.)

Why would you ever want your error.jsp to create a session?  Sounds like an 
easy DoS attack to me.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/10/15 12:26 PM, Jeffrey Janner wrote:
> Thanks for all the help guys. I think I've sussed out what is
> going on here.  Now just have to get the Dev guys to address it.
> 
> After spending a good bit of time clearing and watching cookies
> and access logs, both with and without a favicon.ico file, I found
> that the doubling was happening only if the file was missing.  I
> checked the error.jsp file and it does have session=true set, and
> if the icon file is missing, the error.jsp is definitely being
> sent.
> 
> So it looks like the possible solutions are: 1) provide a
> favicon.ico file.

This fixes the symptom, not the problem. You'll get the same problem
with clients who request /apple-touch-icon.png, /robots.txt, or just
about any other file that ends up resulting in a 404. This could be
something from within the application itself, and will (apparently)
cause mass confusion.

> 2) remove the session=true setting from the error page.

This is the right answer. Do you really need the session in error.jsp?

> 3) somehow not send the error.jsp when a sub-link (image, script, 
> etc.) results in a 404.
> 
> 4) Have the login page of APP2 provide it's own icon  
> directive (it doesn't currently have one.)

> Any other options?

If you absolutely need access to the session in your error.jsp file,
you can do this:


<%
  HttpSession session = request.getSession(false);

  ...
%>

This will prevent sessions from being created when there isn't already
a session. You'll have to check the code for error.jsp to make sure
that no code uses the session before checking it for null -- because
session="true" guarantees that the "session" reference will be non-null.

That will allow you to use session information in error.jsp if a
session already exists, but not create a superfluous session when one
does not (yet) exist.

Back to Tomcat's session management: Tomcat *can* handle this
situation properly: it will try all JSESSIONID cookies it gets to find
a valid one in the current web application. So, multiple JSESSIONID
cookies won't confuse Tomcat. Some other component must be
mis-understanding the session identifier in some way.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8di9AAoJEBzwKT+lPKRY9FUP/0m2SNIG3nW9dsIRCr1q/SWG
5O/s5VrDs7Rvk1hWfbGTlhfuL0zkeCaL/GQE4wa3KQo4qHPhtzYlIgZstEeaAQqk
kLwU4JHzJcTfKMKog6/O0kFwysYzl4y/EX+UoBcY3h3N5xkQ0RGNOYEF7fSr+6NA
Uuxo6WVxQoP3Ce/64EZ1P+uxglLJF+pML6OViEHEK4qgL3SY1UY0tOFpcBa43Gqt
Y/Z7I1SvQhRt2VGQzyatHRypAMxynJfHjvV/gyF3k1/XFEeWDDpET4guaazD1uqW
fE5Lgt3Lxr1WyeEXxeJz4jOlLBty0bm9m16YFdxCsNjVy7v7Uy7M1Hd0iIfoktCV
Vp8nzuj+qxVMpzua2N/J7e9slYnIZOePOFFrTQbWx1S10QCvgRuprN3lyZEU29oP
PywXQU/F9u/xFPk6Z5+xdMrSEvL+ykuwoyV8Ef2CObZ0Ibsjx9WoBAz/hRLpeeji
TngPwFvDrU7jMR36SQ+vCR8PQSjQo5P2P+KZE735uIgG/iz3F6gQ+8R9E0p1iutL
iLoF2alPkSaoWnBTrlDhV+EvKtjKl2FWuRrs5sHGWG6FowS+lKnaAfhkq3ArGLdS
j4JFculpE80Ys9saoetvTlQ35dTi1KdmL+gzixI/EjUVkS2azsW6kYxkwliig4gN
UVa6wuFsD/I9JcMCKeIp
=1OQG
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Igor Cicimov [mailto:icici...@gmail.com]
> Sent: Tuesday, September 08, 2015 10:09 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> On 09/09/2015 7:13 AM, "Jeffrey Janner" <jeffrey.jan...@polydyne.com>
> wrote:
> >
> > > -Original Message-
> > > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > > Sent: Tuesday, September 08, 2015 9:22 AM
> > > To: Tomcat Users List <users@tomcat.apache.org>
> > > Subject: Re: Multiple JSESSIONID cookies being presented.
> > >
> > > 2015-09-08 15:51 GMT+02:00 Jeffrey Janner
> <jeffrey.jan...@polydyne.com>:
> > > >> -Original Message-
> > > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > >> Sent: Friday, September 04, 2015 12:46 PM
> > > >> To: Tomcat Users List <users@tomcat.apache.org>
> > > >> Subject: Re: Multiple JSESSIONID cookies being presented.
> > > >>
> > > >> -BEGIN PGP SIGNED MESSAGE-
> > > >> Hash: SHA256
> > > >>
> > > >> Jeffrey,
> > > >>
> > > > Now, it's been doing this since at least Tomcat 6, I have one
> running
> > > now, and I've never had a problem with it using direct connections.
> But
> > > now we are front-ending with HaProxy and going to two backend
> tomcats,
> > > and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> > > multiple cookies is confusing HaProxy. (Yes, I'm going to ask that
> user
> > > community.)
> > > > Jeff
> > >
> > >
> > > You could use another cookie to implement stickyness
> > >
> > > "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> > > backend. Then simply add the cookie directive within each server.
> Then
> > > HAProxy will append a cookie (or add onto an existing one) a
> > > identifier for each server. This cookie will be sent back in
> > > subsequent requests from the client, letting HAProxy know which
> server
> > > to send the request to. This looks like the following:"
> > >
> > > backend nodes
> > > # Other options above omitted for brevity
> > >  cookie SRV_ID prefix
> > > server web01 127.0.0.1:9000 cookie check
> > > server web02 127.0.0.1:9001 cookie check
> > > server web03 127.0.0.1:9002 cookie check
> > >
> > >
> > > https://serversforhackers.com/load-balancing-with-haproxy
> > >
> > Thanks Jose.  We considered that, as well as having HaProxy just
> generate
> its own sticky-session cookie, but it seemed like a better idea to just
> let
> Tomcat handle it and use stick-tables. We are moving towards a
> fully-clustered tomcat, so already having the config in place such that
> we
> only have to turn off the stick-tables and we'd be set to go. I'll
> eventually be supporting a fairly large number of backends and don't
> want
> to make the configuration of new ones very complicated. Making them
> simple
> and pushing the complication down to the tomcat level just seemed to
> make
> more sense.
> 
> If using more than one haproxy inserting its own cookie is much better
> solution since you don't have to sync the stick tables between the lb's.
> 
> > In fact, I've parameterized the jvmRoute setting in the Tomcat
> server.xml
> and use the setenv.sh script to calculate the value based on the server
> the
> Tomcat is running on.
> > If only there were some way to have HaProxy read an already existing
> suffix in the cookie string, like httpd, my life would be perfect.
> > Jeff
Thanks Igor.  We may have to look into that in the future. We are running 
multiple HaProxy servers relying on Round robin DNS, so we need to have some 
method of insuring a consistent cookie between the two HaProxy servers. 
Thanks again.

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
> Sent: Tuesday, September 08, 2015 4:58 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> > > Thanks for the clarification of what's supposed to happen on
> receipt, Jose.
> > > However, I am describing what happens on first contact from the
> client to the server.
> > > The browser sends https://hostname/APP2, and Tomcat returns:
> > > JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/
> 
> > Indeed, it doesn't make sense for me to return different id (  ,
> >  ) if you are accesing to only one context (/APP2)
> 
> > Are you sure that your webapp deployed in /APP2 is not accesing to
> > resources ( session-aware resources as JSP, servlet, .. .I mean)
> > stored in ROOT context ?
> 
> As I think someone previously mentioned, the client (browser) may well
> be sending an unsolicited request to the default webapp, such as when
> trying to retrieve favicon.ico.  You might want to run Fiddler or
> Wireshark on the client to see exactly what's being sent to the server.
> 

And there's no way to keep a browser from asking for the favicon.ico file from 
the root. 
We don't have one, so I would expect a 404 is sent, which looking at the access 
log file is what happens.
However, is this the issue?  I tested this doing a manual 
https://hostname/favicon.ico and see that we also return our root app's error 
page. We also seem to be doing that for the auto-generated request, judging by 
the bytes returned value, even though it won't get displayed.
And I bet that the error page is setting the session cookie for some reason.
Does that sound reasonable?  
Is my solution just providing a favicon.ico file?
Jeff

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/9/15 12:08 PM, Jeffrey Janner wrote:
>> -Original Message- From: Caldarale, Charles R
>> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08,
>> 2015 4:58 PM To: Tomcat Users List <users@tomcat.apache.org> 
>> Subject: RE: Multiple JSESSIONID cookies being presented.
>> 
>>> From: Jose María Zaragoza [mailto:demablo...@gmail.com] 
>>> Subject: Re: Multiple JSESSIONID cookies being presented.
>> 
>>>> Thanks for the clarification of what's supposed to happen on
>> receipt, Jose.
>>>> However, I am describing what happens on first contact from
>>>> the
>> client to the server.
>>>> The browser sends https://hostname/APP2, and Tomcat returns: 
>>>> JSESSIONID=, path=/and   JSESSIONID=,
>>>> path=/APP2/
>> 
>>> Indeed, it doesn't make sense for me to return different id (
>>>  ,  ) if you are accesing to only one context (/APP2)
>> 
>>> Are you sure that your webapp deployed in /APP2 is not accesing
>>> to resources ( session-aware resources as JSP, servlet, .. .I
>>> mean) stored in ROOT context ?
>> 
>> As I think someone previously mentioned, the client (browser) may
>> well be sending an unsolicited request to the default webapp,
>> such as when trying to retrieve favicon.ico.  You might want to
>> run Fiddler or Wireshark on the client to see exactly what's
>> being sent to the server.
>> 
> 
> And there's no way to keep a browser from asking for the
> favicon.ico file from the root. We don't have one, so I would
> expect a 404 is sent, which looking at the access log file is what
> happens. However, is this the issue?  I tested this doing a manual
> https://hostname/favicon.ico and see that we also return our root
> app's error page. We also seem to be doing that for the
> auto-generated request, judging by the bytes returned value, even
> though it won't get displayed. And I bet that the error page is
> setting the session cookie for some reason. Does that sound
> reasonable? Is my solution just providing a favicon.ico file?

Can you make sure that all cookies have been cleared from the test
client and then explain exactly when Tomcat sends the Set-Cookie headers
?

When we had this problem, it was usually because the client had old
funky session ids in its cookie jar and the solution was to blow them
all away and start-over fresh. (Then fix our software so it wouldn't
happen anymore.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8H9WAAoJEBzwKT+lPKRYUrUP/jFofb1kyXtipLisOXrDRKRi
dXgapMR+XsBMUNBqQOCbwM1YRn2IV9+pF2oJaLtN/R36rweoYMywvbqc6LWG+MuL
oOu8Qe7t5RRXVbOdvP5hYPTNiVDNGPYSmPHg5gbGsPNfhUWqMNutWbQBxZwjX+kH
Q0P71bgk2Nf4Ch0wqjQImCsO+oQH2BeHUOCC7FLYsRa8r8nS8Ml0MXmvQl57yZzB
cUm/V4Z1ygh8QxvB2ZmIber2KFVx4gJyZh6usTnpkb0lm7x1H0PUylpklyYSTJKv
thR3DSgVjLe582I8/2/rIjpGhqqP/TUAv9INh7WprzLGTb4wQQRKkPYAwy/9vxhI
4+PDs6qTalS9iti8GdA5MIg6CuK55Gu26rvlC+FNSsYQMMMzedySTri1tJQgCkJd
JQL97eoouNFd3K06EuCyUWIoOfGqCNNoYpDYaxN/IeBwbefSR8mUctWsWKDdX6MJ
p7/I3saRu3na8oLR4nnZz8a/I/oIQWwvJebHMN3UFuSgBLxIwgurE6LHZ8tSP2YP
D/QYKSnY+KoGb7tPR4O0FTxr7EULUFtVgWPCy6WePi1jkVxqmKPD3rIU+TtPzwLb
QDiI4W4O3lL97F1iZNcjNGnbDgpOcJdhJjORFQl/KEX8r6D9fN0h0LjgSuuEJnr7
JrNmcEq8wsZxM1VgxtRn
=ZL2V
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/4/15 4:40 PM, Jeffrey Janner wrote:
> I'm surprised that Tomcat would use the "wrong" session id for 
> URL-rewriting when presenting the login screen. Are you saying
> that, when showing the login page for /APP2, Tomcat will:
> 
> a. Place a session identifier in the URL with value X b. Return a
> Set-Cookie response header for JSESSIONID with value Y
> 
> Where X != Y?
>> So far, it looks like it is maintaining an X=Y philosophy. So
>> that's a non-starter.

Maybe we aren't communicating well: I'd expect to see X = Y *100% of
the time*. The session id for both the URL *and* the cookie should be
the same, otherwise mass confusion would ensue.

> But you do use Tomcat's session-tracking mechanisms, right?
> 
>> Yes, and the problem only rears its ugly head on a successful
>> login (app expires old cookie, creates a new one).

Usually, Tomcat won't explicitly expire an old JSESSIONID cookie...
just set another one with a new value. The browser should replace the
old value with the new one.

>> User never even sees a new page, just an app-generated "session 
>> expired" error. Trying to see things in access logs, but nothing 
>> there I can see.

Hmm.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8H7uAAoJEBzwKT+lPKRYf30QAJ6V2G22zeRhRS7pl3rkhk7w
4/de4gpP+HfS/TYdOrLWr/qn26VPM38xjqPTuOvLTTGNfqgTdKhhrpQwEtHA9iSj
9K3oFmoEN7vXxshKjp2Q5bmjKemez1NVX43bwolq8+fTjVSlGZwTZcSA8+n2rJ05
vV5mBT+O4iqdYT1L1zdUj8XGWBS7hDmL9XCJM+08c4Rxajin37J4Xebi1HBAIM5a
WLijOUNAGHnkfDfpipxBgRcPly/wj//D0TdAZRMLqjVBh3DN6Lxhi59IOIiQgOYc
vu7l+GsimC1QI9/qM88JYlOXzJqpncjdYddyiJXdjvs1b7Rqk2QFGNyzE+njtPYK
icatILkejaN4Ic73mZZtHck50uY7vUagoZCAgsi48vMxsNXraFqrsN6NlKVVI3RN
L11+z7+qftoirWKGgTFmADikm/sknYiaezaVRIYLJohADONeQQ0sd9NpR4LQOU1x
87kWL+6rNfhNrnsWlGpm9PiBY4ZhmfpTcgK5iIJG3/2teCpk6sjye0BuVxkgQUPd
cHiTrhZgEVfkroWLTt55pKvIJmpX6BMA0R43UOk6NwTUrc0oKVqnZvkTMxt95b0m
lhHTRGFloCK3vKpz6ebeKowLz0Pc9rRBn6sQAANZgPd67m8XGjUDZ5lNBuz7XH/D
SfggjrqFB4x52K+EDETR
=LgVZ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Jose María Zaragoza]

2015-09-09 18:08 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
>> -Original Message-
>> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
>> Sent: Tuesday, September 08, 2015 4:58 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: RE: Multiple JSESSIONID cookies being presented.
>>
>> > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
>> > Subject: Re: Multiple JSESSIONID cookies being presented.
>>
>> > > Thanks for the clarification of what's supposed to happen on
>> receipt, Jose.
>> > > However, I am describing what happens on first contact from the
>> client to the server.
>> > > The browser sends https://hostname/APP2, and Tomcat returns:
>> > > JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/
>>
>> > Indeed, it doesn't make sense for me to return different id (  ,
>> >  ) if you are accesing to only one context (/APP2)
>>
>> > Are you sure that your webapp deployed in /APP2 is not accesing to
>> > resources ( session-aware resources as JSP, servlet, .. .I mean)
>> > stored in ROOT context ?
>>
>> As I think someone previously mentioned, the client (browser) may well
>> be sending an unsolicited request to the default webapp, such as when
>> trying to retrieve favicon.ico.  You might want to run Fiddler or
>> Wireshark on the client to see exactly what's being sent to the server.
>>
>
> And there's no way to keep a browser from asking for the favicon.ico file 
> from the root.
> We don't have one, so I would expect a 404 is sent, which looking at the 
> access log file is what happens.
> However, is this the issue?  I tested this doing a manual 
> https://hostname/favicon.ico and see that we also return our root app's error 
> page. We also seem to be doing that for the auto-generated request, judging 
> by the bytes returned value, even though it won't get displayed.
> And I bet that the error page is setting the session cookie for some reason.
> Does that sound reasonable?

If you write https://hostname/favicon.ico into your browser's url address bar
does it return a JSESSIONID ?
If it does , why do your error html page is creating a HTTP session ?
Is it a error.jsp ?





> Is my solution just providing a favicon.ico file?
> Jeff
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> Sent: Tuesday, September 08, 2015 9:22 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Friday, September 04, 2015 12:46 PM
> >> To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Jeffrey,
> >>
> > Now, it's been doing this since at least Tomcat 6, I have one running
> now, and I've never had a problem with it using direct connections.  But
> now we are front-ending with HaProxy and going to two backend tomcats,
> and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user
> community.)
> > Jeff
> 
> 
> You could use another cookie to implement stickyness
> 
> "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> backend. Then simply add the cookie directive within each server. Then
> HAProxy will append a cookie (or add onto an existing one) a
> identifier for each server. This cookie will be sent back in
> subsequent requests from the client, letting HAProxy know which server
> to send the request to. This looks like the following:"
> 
> backend nodes
> # Other options above omitted for brevity
>  cookie SRV_ID prefix
> server web01 127.0.0.1:9000 cookie check
> server web02 127.0.0.1:9001 cookie check
> server web03 127.0.0.1:9002 cookie check
> 
> 
> https://serversforhackers.com/load-balancing-with-haproxy
> 
Thanks Jose.  We considered that, as well as having HaProxy just generate its 
own sticky-session cookie, but it seemed like a better idea to just let Tomcat 
handle it and use stick-tables. We are moving towards a fully-clustered tomcat, 
so already having the config in place such that we only have to turn off the 
stick-tables and we'd be set to go. I'll eventually be supporting a fairly 
large number of backends and don't want to make the configuration of new ones 
very complicated. Making them simple and pushing the complication down to the 
tomcat level just seemed to make more sense.
In fact, I've parameterized the jvmRoute setting in the Tomcat server.xml and 
use the setenv.sh script to calculate the value based on the server the Tomcat 
is running on.
If only there were some way to have HaProxy read an already existing suffix in 
the cookie string, like httpd, my life would be perfect.
Jeff

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Caldarale, Charles R]

> From: Jose María Zaragoza [mailto:demablo...@gmail.com] 
> Subject: Re: Multiple JSESSIONID cookies being presented.

> > Thanks for the clarification of what's supposed to happen on receipt, Jose.
> > However, I am describing what happens on first contact from the client to 
> > the server.
> > The browser sends https://hostname/APP2, and Tomcat returns:
> > JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/

> Indeed, it doesn't make sense for me to return different id (  ,
>  ) if you are accesing to only one context (/APP2)

> Are you sure that your webapp deployed in /APP2 is not accesing to
> resources ( session-aware resources as JSP, servlet, .. .I mean)
> stored in ROOT context ?

As I think someone previously mentioned, the client (browser) may well be 
sending an unsolicited request to the default webapp, such as when trying to 
retrieve favicon.ico.  You might want to run Fiddler or Wireshark on the client 
to see exactly what's being sent to the server.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> Sent: Tuesday, September 08, 2015 9:08 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Friday, September 04, 2015 12:46 PM
> >> To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Jeffrey,
> >>
> >> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> >> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> >> > also seeing this on Windows (version doesn't matter), with Tomcat
> >> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >> >
> >> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> >> > APP2. Both contexts start off at a login screen unique to the
> >> > context and provided by it (not using container auth).
> >> >
> >> > When I connect to ROOT, no problem, but when I connect to APP2, I
> >> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> >> > the path "/APP2/".
> >>
> >> I would expect this behavior: you have one ROOT app (cookie path=/)
> >> and one APP2 app (cookie path=/APP2). Your browser will send both
> >> cookies to /APP2 because / is a prefix of /APP2.
> >>
> > Chris -
> > I wanted to come back to this case.
> > Why is the above "expected behavior"?
> > The client is connecting directly as "https://hostname/APP2; and never
> going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on
> first connection.  To me, this seems like a bug.
> > Only being an admin, I've not fully read the spec, so not sure if the
> above is really expected behavior.
> 
> 
> http://www.ietf.org/rfc/rfc2109.txt
> 
> The following rules apply to choosing applicable cookie-values from
>among all the cookies the user agent has.
> 
> Domain Selection
> The origin server's fully-qualified host name must domain-match
> the Domain attribute of the cookie.
> 
>Path Selection
> The Path attribute of the cookie must match a prefix of the
> request-URI.
> 
>Max-Age Selection
> Cookies that have expired should have been discarded and thus
> are not forwarded to an origin server.
> 
>If multiple cookies satisfy the criteria above, they are ordered in
>the Cookie header such that those with more specific Path attributes
>precede those with less specific.  Ordering with respect to other
>attributes (e.g., Domain) is unspecified.
> 
> 
> 
Thanks for the clarification of what's supposed to happen on receipt, Jose.
However, I am describing what happens on first contact from the client to the 
server.
The browser sends https://hostname/APP2, and Tomcat returns:
JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/

My contention is that it shouldn't be sending the first one, since it should 
never route the request to the ROOT app, so it should not be generating a 
cookie for it.

However, taking what you say above at face value, are you saying that HaProxy 
should only be forwarding the cookie with path=/APP2/ or should it forward all 
of them and let Tomcat figure it out.

Jeff

Re: Multiple JSESSIONID cookies being presented.

[Jose María Zaragoza]

2015-09-08 22:57 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
>> -Original Message-
>> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
>> Sent: Tuesday, September 08, 2015 9:08 AM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: Multiple JSESSIONID cookies being presented.
>>
>> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
>> >> -Original Message-
>> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> >> Sent: Friday, September 04, 2015 12:46 PM
>> >> To: Tomcat Users List <users@tomcat.apache.org>
>> >> Subject: Re: Multiple JSESSIONID cookies being presented.
>> >>
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA256
>> >>
>> >> Jeffrey,
>> >>
>> >> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
>> >> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
>> >> > also seeing this on Windows (version doesn't matter), with Tomcat
>> >> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
>> >> >
>> >> > I have 2 contexts installed in Tomcat, one is ROOT, the other
>> >> > APP2. Both contexts start off at a login screen unique to the
>> >> > context and provided by it (not using container auth).
>> >> >
>> >> > When I connect to ROOT, no problem, but when I connect to APP2, I
>> >> > get 2 JSESSIONID cookies, one with the path "/" and the other with
>> >> > the path "/APP2/".
>> >>
>> >> I would expect this behavior: you have one ROOT app (cookie path=/)
>> >> and one APP2 app (cookie path=/APP2). Your browser will send both
>> >> cookies to /APP2 because / is a prefix of /APP2.
>> >>
>> > Chris -
>> > I wanted to come back to this case.
>> > Why is the above "expected behavior"?
>> > The client is connecting directly as "https://hostname/APP2; and never
>> going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on
>> first connection.  To me, this seems like a bug.
>> > Only being an admin, I've not fully read the spec, so not sure if the
>> above is really expected behavior.
>>
>>
>> http://www.ietf.org/rfc/rfc2109.txt
>>
>> The following rules apply to choosing applicable cookie-values from
>>among all the cookies the user agent has.
>>
>> Domain Selection
>> The origin server's fully-qualified host name must domain-match
>> the Domain attribute of the cookie.
>>
>>Path Selection
>> The Path attribute of the cookie must match a prefix of the
>> request-URI.
>>
>>Max-Age Selection
>> Cookies that have expired should have been discarded and thus
>> are not forwarded to an origin server.
>>
>>If multiple cookies satisfy the criteria above, they are ordered in
>>the Cookie header such that those with more specific Path attributes
>>precede those with less specific.  Ordering with respect to other
>>attributes (e.g., Domain) is unspecified.
>>
>>
>>
> Thanks for the clarification of what's supposed to happen on receipt, Jose.
> However, I am describing what happens on first contact from the client to the 
> server.
> The browser sends https://hostname/APP2, and Tomcat returns:
> JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/

Sorry, I misunderstood
IMHO, that behaviour is strange .
Indeed, it doesn't make sense for me to return different id (  ,
 ) if you are accesing to only one context (/APP2)

Are you sure that your webapp deployed in /APP2 is not accesing to
resources ( session-aware resources as JSP, servlet, .. .I mean)
stored in ROOT context ?


>
> My contention is that it shouldn't be sending the first one, since it should 
> never route the request to the ROOT app, so it should not be generating a 
> cookie for it.
>
> However, taking what you say above at face value, are you saying that HaProxy 
> should only be forwarding the cookie with path=/APP2/ or should it forward 
> all of them and let Tomcat figure it out.

I don't know.
In a later email, I talked you about using another cookie ( SRV_ID )
to balance between backend servers. This feature is implemented by HA
Proxy ( 1.5 at least )


>
> Jeff

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 12:46 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> > also seeing this on Windows (version doesn't matter), with Tomcat
> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >
> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> > APP2. Both contexts start off at a login screen unique to the
> > context and provided by it (not using container auth).
> >
> > When I connect to ROOT, no problem, but when I connect to APP2, I
> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> > the path "/APP2/".
> 
> I would expect this behavior: you have one ROOT app (cookie path=/)
> and one APP2 app (cookie path=/APP2). Your browser will send both
> cookies to /APP2 because / is a prefix of /APP2.
> 
Chris -
I wanted to come back to this case. 
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2; and never going 
directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on first 
connection.  To me, this seems like a bug.
Only being an admin, I've not fully read the spec, so not sure if the above is 
really expected behavior.
Now, it's been doing this since at least Tomcat 6, I have one running now, and 
I've never had a problem with it using direct connections.  But now we are 
front-ending with HaProxy and going to two backend tomcats, and using the 
JSESSIONID to support sticky-sessions.  I'm afraid the multiple cookies is 
confusing HaProxy. (Yes, I'm going to ask that user community.)
Jeff

Re: Multiple JSESSIONID cookies being presented.

[Jose María Zaragoza]

2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Friday, September 04, 2015 12:46 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: Multiple JSESSIONID cookies being presented.
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Jeffrey,
>>
>> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
>> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
>> > also seeing this on Windows (version doesn't matter), with Tomcat
>> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
>> >
>> > I have 2 contexts installed in Tomcat, one is ROOT, the other
>> > APP2. Both contexts start off at a login screen unique to the
>> > context and provided by it (not using container auth).
>> >
>> > When I connect to ROOT, no problem, but when I connect to APP2, I
>> > get 2 JSESSIONID cookies, one with the path "/" and the other with
>> > the path "/APP2/".
>>
>> I would expect this behavior: you have one ROOT app (cookie path=/)
>> and one APP2 app (cookie path=/APP2). Your browser will send both
>> cookies to /APP2 because / is a prefix of /APP2.
>>
> Chris -
> I wanted to come back to this case.
> Why is the above "expected behavior"?
> The client is connecting directly as "https://hostname/APP2; and never going 
> directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on first 
> connection.  To me, this seems like a bug.
> Only being an admin, I've not fully read the spec, so not sure if the above 
> is really expected behavior.


http://www.ietf.org/rfc/rfc2109.txt

The following rules apply to choosing applicable cookie-values from
   among all the cookies the user agent has.

Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.

   Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.

   Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.

   If multiple cookies satisfy the criteria above, they are ordered in
   the Cookie header such that those with more specific Path attributes
   precede those with less specific.  Ordering with respect to other
   attributes (e.g., Domain) is unspecified.



> Now, it's been doing this since at least Tomcat 6, I have one running now, 
> and I've never had a problem with it using direct connections.  But now we 
> are front-ending with HaProxy and going to two backend tomcats, and using the 
> JSESSIONID to support sticky-sessions.  I'm afraid the multiple cookies is 
> confusing HaProxy. (Yes, I'm going to ask that user community.)
> Jeff
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Jose María Zaragoza]

2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Friday, September 04, 2015 12:46 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: Multiple JSESSIONID cookies being presented.
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Jeffrey,
>>
> Now, it's been doing this since at least Tomcat 6, I have one running now, 
> and I've never had a problem with it using direct connections.  But now we 
> are front-ending with HaProxy and going to two backend tomcats, and using the 
> JSESSIONID to support sticky-sessions.  I'm afraid the multiple cookies is 
> confusing HaProxy. (Yes, I'm going to ask that user community.)
> Jeff


You could use another cookie to implement stickyness

"You can add a cookie SOME-COOKIE-NAME prefix directive into the
backend. Then simply add the cookie directive within each server. Then
HAProxy will append a cookie (or add onto an existing one) a
identifier for each server. This cookie will be sent back in
subsequent requests from the client, letting HAProxy know which server
to send the request to. This looks like the following:"

backend nodes
# Other options above omitted for brevity
 cookie SRV_ID prefix
server web01 127.0.0.1:9000 cookie check
server web02 127.0.0.1:9001 cookie check
server web03 127.0.0.1:9002 cookie check


https://serversforhackers.com/load-balancing-with-haproxy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Igor Cicimov]

On 09/09/2015 7:13 AM, "Jeffrey Janner" <jeffrey.jan...@polydyne.com> wrote:
>
> > -Original Message-
> > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > Sent: Tuesday, September 08, 2015 9:22 AM
> > To: Tomcat Users List <users@tomcat.apache.org>
> > Subject: Re: Multiple JSESSIONID cookies being presented.
> >
> > 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
> > >> -Original Message-
> > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > >> Sent: Friday, September 04, 2015 12:46 PM
> > >> To: Tomcat Users List <users@tomcat.apache.org>
> > >> Subject: Re: Multiple JSESSIONID cookies being presented.
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >> Hash: SHA256
> > >>
> > >> Jeffrey,
> > >>
> > > Now, it's been doing this since at least Tomcat 6, I have one running
> > now, and I've never had a problem with it using direct connections.  But
> > now we are front-ending with HaProxy and going to two backend tomcats,
> > and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> > multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user
> > community.)
> > > Jeff
> >
> >
> > You could use another cookie to implement stickyness
> >
> > "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> > backend. Then simply add the cookie directive within each server. Then
> > HAProxy will append a cookie (or add onto an existing one) a
> > identifier for each server. This cookie will be sent back in
> > subsequent requests from the client, letting HAProxy know which server
> > to send the request to. This looks like the following:"
> >
> > backend nodes
> > # Other options above omitted for brevity
> >  cookie SRV_ID prefix
> > server web01 127.0.0.1:9000 cookie check
> > server web02 127.0.0.1:9001 cookie check
> > server web03 127.0.0.1:9002 cookie check
> >
> >
> > https://serversforhackers.com/load-balancing-with-haproxy
> >
> Thanks Jose.  We considered that, as well as having HaProxy just generate
its own sticky-session cookie, but it seemed like a better idea to just let
Tomcat handle it and use stick-tables. We are moving towards a
fully-clustered tomcat, so already having the config in place such that we
only have to turn off the stick-tables and we'd be set to go. I'll
eventually be supporting a fairly large number of backends and don't want
to make the configuration of new ones very complicated. Making them simple
and pushing the complication down to the tomcat level just seemed to make
more sense.

If using more than one haproxy inserting its own cookie is much better
solution since you don't have to sync the stick tables between the lb's.

> In fact, I've parameterized the jvmRoute setting in the Tomcat server.xml
and use the setenv.sh script to calculate the value based on the server the
Tomcat is running on.
> If only there were some way to have HaProxy read an already existing
suffix in the cookie string, like httpd, my life would be perfect.
> Jeff
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

Hi folks,
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm also seeing 
this on Windows (version doesn't matter), with Tomcat 7.0.57 and Java 7u71, and 
Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other APP2.  Both 
contexts start off at a login screen unique to the context and provided by it 
(not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I get 2 
JSESSIONID cookies, one with the path "/" and the other with the path "/APP2/".
On the Windows implementations, we are not seeing a problem, at least not one 
being reported.
On the Linux implementation, the end user will occasionally get immediately 
kicked out with an invalid session immediately after providing credentials. The 
access logs show a single jsessionid=xxx being provided on the POST URL.  
Amazingly, sometimes that goes through and lets the user login, so my theory is 
that the browser is sometimes picking the wrong path.  (Also, theory, the "/" 
cookie is being generated by a request for "/favicon.ico" just before the 
request for the login page.)

So my question is:  Is there anything I can do from a configuration perspective 
to get it to NOT send the "/" cookie for APP2?

Deployment details:
Linux is being fronted by an HaProxy server, but the traffic appears to be 
staying on one host.
Server.xml is essentially the basic one provided with install.  Port # and 
access log information is modified and has RemoteIpValve setup so we can log 
the end user's IP.
Apps are deployed as war files with static context.xml files in 
Catalina/localhost.  Those files all look like:

  
  

War files do get exploded.  I can't find anything in the web.xml files that 
have anything to do with cookies.

Any help here would be appreciated.

Jeffrey Janner

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 12:46 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> > also seeing this on Windows (version doesn't matter), with Tomcat
> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >
> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> > APP2. Both contexts start off at a login screen unique to the
> > context and provided by it (not using container auth).
> >
> > When I connect to ROOT, no problem, but when I connect to APP2, I
> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> > the path "/APP2/".
> 
> I would expect this behavior: you have one ROOT app (cookie path=/)
> and one APP2 app (cookie path=/APP2). Your browser will send both
> cookies to /APP2 because / is a prefix of /APP2.
> 
> > On the Windows implementations, we are not seeing a problem, at
> > least not one being reported.
> >
> > On the Linux implementation, the end user will occasionally get
> > immediately kicked out with an invalid session immediately after
> > providing credentials. The access logs show a single
> > jsessionid=xxx being provided on the POST URL.
> 
> The POST to j_security_check?
> 
No

> Are you using request.encodeURL() to build the  action URL, or
> are you building it manually?
> 
EncodeUrl.  And a check of a couple of sites, both linux and windows, shows 
that the jsessionid is being added to the action by EncodeUrl, regardless of 
cookie settings. So far, it is always the APP2 sessionID.

> I believe Tomcat prefers the Cookie-based session id to anything
> coming-in from the URL, and I do know it will search all JSESSIONID
> cookies for any that match a valid session (not just the first one) in
> the current application. So logging-in should ... always work.
> 
> > Amazingly, sometimes that goes through and lets the user login, so
> > my theory is that the browser is sometimes picking the wrong path.
> > (Also, theory, the "/" cookie is being generated by a request for
> > "/favicon.ico" just before the request for the login page.)
> 
> You should make sure that anything that doesn't require authentication
> specifically mentions that in web.xml, otherwise you'll get weird
> things happening like that.
> 
We don't actually use Tomcat container authentication at all.

> > So my question is:  Is there anything I can do from a
> > configuration perspective to get it to NOT send the "/" cookie for
> > APP2?
> 
> Not really... other than changing from ROOT to APP1 or whatever.
> Overlapping URL spaces for applications leads to tears.
> 
I could do that, though we'd like to keep it so that if no context is specified 
we still go to APP1, so the user's don't have to change all of their bookmarks. 
 Perhaps with a redirect?

> > Deployment details:
> 
> I think there's nothing in here that would change anything.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO
> qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG
> 0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf
> VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0
> yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc
> Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf
> BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w
> QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS
> 5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw
> WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m
> KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn
> 7v5mbzif9Ira1ZGLFBjC
> =5N0l
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/4/15 3:31 PM, Jeffrey Janner wrote:
>> -Original Message- From: Christopher Schultz
>> [mailto:ch...@christopherschultz.net] Sent: Friday, September 04,
>> 2015 12:46 PM To: Tomcat Users List <users@tomcat.apache.org> 
>> Subject: Re: Multiple JSESSIONID cookies being presented.
>> 
> Jeffrey,
> 
> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
>>>> I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but
>>>> I'm also seeing this on Windows (version doesn't matter),
>>>> with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java
>>>> 7U51.
>>>> 
>>>> I have 2 contexts installed in Tomcat, one is ROOT, the
>>>> other APP2. Both contexts start off at a login screen unique
>>>> to the context and provided by it (not using container
>>>> auth).
>>>> 
>>>> When I connect to ROOT, no problem, but when I connect to
>>>> APP2, I get 2 JSESSIONID cookies, one with the path "/" and
>>>> the other with the path "/APP2/".
> 
> I would expect this behavior: you have one ROOT app (cookie
> path=/) and one APP2 app (cookie path=/APP2). Your browser will
> send both cookies to /APP2 because / is a prefix of /APP2.
> 
>>>> On the Windows implementations, we are not seeing a problem,
>>>> at least not one being reported.
>>>> 
>>>> On the Linux implementation, the end user will occasionally
>>>> get immediately kicked out with an invalid session
>>>> immediately after providing credentials. The access logs show
>>>> a single jsessionid=xxx being provided on the POST URL.
> 
> The POST to j_security_check?
> 
>> No

So... where does the POST go?

> Are you using request.encodeURL() to build the  action URL,
> or are you building it manually?
> 
>> EncodeUrl.  And a check of a couple of sites, both linux and 
>> windows, shows that the jsessionid is being added to the action
>> by EncodeUrl, regardless of cookie settings. So far, it is always
>> the APP2 sessionID.

I'm not surprised that the session id is being added to the URL
regardless of cookie settings, because at that point, Tomcat might not
know for sure if the client can support cookies. (I'm sure there are
cases where it's obvious that cookies are in fact supported, but
Tomcat is not detecting it.)

I'm surprised that Tomcat would use the "wrong" session id for
URL-rewriting when presenting the login screen. Are you saying that,
when showing the login page for /APP2, Tomcat will:

a. Place a session identifier in the URL with value X
b. Return a Set-Cookie response header for JSESSIONID with value Y

Where X != Y?

> I believe Tomcat prefers the Cookie-based session id to anything 
> coming-in from the URL, and I do know it will search all
> JSESSIONID cookies for any that match a valid session (not just the
> first one) in the current application. So logging-in should ...
> always work.
> 
>>>> Amazingly, sometimes that goes through and lets the user
>>>> login, so my theory is that the browser is sometimes picking
>>>> the wrong path. (Also, theory, the "/" cookie is being
>>>> generated by a request for "/favicon.ico" just before the
>>>> request for the login page.)
> 
> You should make sure that anything that doesn't require
> authentication specifically mentions that in web.xml, otherwise
> you'll get weird things happening like that.
> 
>> We don't actually use Tomcat container authentication at all.

Okay, that's good information to have. But you do use Tomcat's
session-tracking mechanisms, right?

>>>> So my question is:  Is there anything I can do from a 
>>>> configuration perspective to get it to NOT send the "/"
>>>> cookie for APP2?
> 
> Not really... other than changing from ROOT to APP1 or whatever. 
> Overlapping URL spaces for applications leads to tears.
> 
>> I could do that, though we'd like to keep it so that if no
>> context is specified we still go to APP1, so the user's don't
>> have to change all of their bookmarks. Perhaps with a redirect?

That kind of thing is tough to do, but possible. Something like this:

# Ignore requests to /APP1
RewriteCond %{REQUEST_URI} ^/APP1
RewriteRule .* - [L]

# Ignore requests to /APP2
RewriteCond %{REQUEST_URI} ^/APP2
RewriteRule .* - [L]

# Re-write other requests
RewriteRule (.*) /APP1\1 [R,L]

Be very careful with the above: it's completely untested and can put
your clients into a redirect loop if you aren't careful and test all
case

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 2:55 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 3:31 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Christopher Schultz
> >> [mailto:ch...@christopherschultz.net] Sent: Friday, September 04,
> >> 2015 12:46 PM To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> > Jeffrey,
> >
> > On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> >>>> I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but
> >>>> I'm also seeing this on Windows (version doesn't matter),
> >>>> with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java
> >>>> 7U51.
> >>>>
> >>>> I have 2 contexts installed in Tomcat, one is ROOT, the
> >>>> other APP2. Both contexts start off at a login screen unique
> >>>> to the context and provided by it (not using container
> >>>> auth).
> >>>>
> >>>> When I connect to ROOT, no problem, but when I connect to
> >>>> APP2, I get 2 JSESSIONID cookies, one with the path "/" and
> >>>> the other with the path "/APP2/".
> >
> > I would expect this behavior: you have one ROOT app (cookie
> > path=/) and one APP2 app (cookie path=/APP2). Your browser will
> > send both cookies to /APP2 because / is a prefix of /APP2.
> >
> >>>> On the Windows implementations, we are not seeing a problem,
> >>>> at least not one being reported.
> >>>>
> >>>> On the Linux implementation, the end user will occasionally
> >>>> get immediately kicked out with an invalid session
> >>>> immediately after providing credentials. The access logs show
> >>>> a single jsessionid=xxx being provided on the POST URL.
> >
> > The POST to j_security_check?
> >
> >> No
> 
> So... where does the POST go?
Direct to back-end processing in the app (as far as I know).

> 
> > Are you using request.encodeURL() to build the  action URL,
> > or are you building it manually?
> >
> >> EncodeUrl.  And a check of a couple of sites, both linux and
> >> windows, shows that the jsessionid is being added to the action
> >> by EncodeUrl, regardless of cookie settings. So far, it is always
> >> the APP2 sessionID.
> 
> I'm not surprised that the session id is being added to the URL
> regardless of cookie settings, because at that point, Tomcat might not
> know for sure if the client can support cookies. (I'm sure there are
> cases where it's obvious that cookies are in fact supported, but
> Tomcat is not detecting it.)
> 
That actually makes sense. 

> I'm surprised that Tomcat would use the "wrong" session id for
> URL-rewriting when presenting the login screen. Are you saying that,
> when showing the login page for /APP2, Tomcat will:
> 
> a. Place a session identifier in the URL with value X
> b. Return a Set-Cookie response header for JSESSIONID with value Y
> 
> Where X != Y?
So far, it looks like it is maintaining an X=Y philosophy.
So that's a non-starter.

> 
> > I believe Tomcat prefers the Cookie-based session id to anything
> > coming-in from the URL, and I do know it will search all
> > JSESSIONID cookies for any that match a valid session (not just the
> > first one) in the current application. So logging-in should ...
> > always work.
> >
> >>>> Amazingly, sometimes that goes through and lets the user
> >>>> login, so my theory is that the browser is sometimes picking
> >>>> the wrong path. (Also, theory, the "/" cookie is being
> >>>> generated by a request for "/favicon.ico" just before the
> >>>> request for the login page.)
> >
> > You should make sure that anything that doesn't require
> > authentication specifically mentions that in web.xml, otherwise
> > you'll get weird things happening like that.
> >
> >> We don't actually use Tomcat container authentication at all.
> 
> Okay, that's good information to have. But you do use Tomcat's
> session-tracking mechanisms, right?
> 
Yes, and the problem only rears its ugly head on a successful login (app 
expires old cookie, creates a new one).
User n

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm 
> also seeing this on Windows (version doesn't matter), with Tomcat 
> 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> 
> I have 2 contexts installed in Tomcat, one is ROOT, the other
> APP2. Both contexts start off at a login screen unique to the
> context and provided by it (not using container auth).
> 
> When I connect to ROOT, no problem, but when I connect to APP2, I
> get 2 JSESSIONID cookies, one with the path "/" and the other with
> the path "/APP2/".

I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.

> On the Windows implementations, we are not seeing a problem, at
> least not one being reported.
> 
> On the Linux implementation, the end user will occasionally get 
> immediately kicked out with an invalid session immediately after 
> providing credentials. The access logs show a single
> jsessionid=xxx being provided on the POST URL.

The POST to j_security_check?

Are you using request.encodeURL() to build the  action URL, or
are you building it manually?

I believe Tomcat prefers the Cookie-based session id to anything
coming-in from the URL, and I do know it will search all JSESSIONID
cookies for any that match a valid session (not just the first one) in
the current application. So logging-in should ... always work.

> Amazingly, sometimes that goes through and lets the user login, so
> my theory is that the browser is sometimes picking the wrong path. 
> (Also, theory, the "/" cookie is being generated by a request for 
> "/favicon.ico" just before the request for the login page.)

You should make sure that anything that doesn't require authentication
specifically mentions that in web.xml, otherwise you'll get weird
things happening like that.

> So my question is:  Is there anything I can do from a
> configuration perspective to get it to NOT send the "/" cookie for
> APP2?

Not really... other than changing from ROOT to APP1 or whatever.
Overlapping URL spaces for applications leads to tears.

> Deployment details:

I think there's nothing in here that would change anything.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO
qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG
0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf
VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0
yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc
Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf
BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w
QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS
5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw
WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m
KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn
7v5mbzif9Ira1ZGLFBjC
=5N0l
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: AW: Rfc6265 cookies starting with a dot

[Mark Thomas]

On 14/04/2015 09:05, Peter Schroer wrote:
 This isn't possible because I'm writing some kind of proxy and I dont't have
 any influence on the websites (and the cookies of course). It would be
 possible to ignore invalid cookies if tomcat could be configured to do so.

The error message is from the application setting the cookie. If
ignoring invalid cookies is an option, could you catch the IAE, ignore
it (or log it) and carry on?

Mark


 
 Greetings Peter
 
 
 -Ursprüngliche Nachricht-
 Von: Mark Thomas [mailto:ma...@apache.org] 
 Gesendet: Dienstag, 14. April 2015 16:02
 An: Tomcat Users List
 Betreff: Re: Rfc6265 cookies starting with a dot
 
 On 14/04/2015 07:53, Peter Schroer wrote:
 Hello,

 I'm using tomcat 8.0.21 with the new Rfc6265 cookie processor. If 
 there are cookies starting with a dot I'm getting the following error:

 java.lang.IllegalArgumentException: An invalid domain [.db-app.de] was 
 specified for this cookie

 org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6
 265Coo
 kieProcessor.java:180)

 org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6
 265Coo
 kieProcessor.java:122)

 org.apache.catalina.connector.Response.generateCookieString(Response.j
 ava:95
 9)

 org.apache.catalina.connector.Response.addCookie(Response.java:907)

 org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.
 java:3
 92)

 org.esigate.servlet.impl.ResponseSender.sendResponse(ResponseSender.ja
 va:70)

 com.bahn.esiExtensions.ExtendedProxyServlet.doFilter(ExtendedProxyServ
 let.ja
 va:104)


 Is there a way to stop tomcat from throwing this error?
 
 Don't use an invalid value for the domain when creating the cookie.
 
 Mark
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Rfc6265 cookies starting with a dot

[Mark Thomas]

On 14/04/2015 07:53, Peter Schroer wrote:
 Hello,
 
 I'm using tomcat 8.0.21 with the new Rfc6265 cookie processor. If there are
 cookies starting with a dot I'm getting the following error:
 
 java.lang.IllegalArgumentException: An invalid domain [.db-app.de] was
 specified for this cookie
 
 org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6265Coo
 kieProcessor.java:180)
 
 org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265Coo
 kieProcessor.java:122)
 
 org.apache.catalina.connector.Response.generateCookieString(Response.java:95
 9)
 
 org.apache.catalina.connector.Response.addCookie(Response.java:907)
 
 org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.java:3
 92)
 
 org.esigate.servlet.impl.ResponseSender.sendResponse(ResponseSender.java:70)
 
 com.bahn.esiExtensions.ExtendedProxyServlet.doFilter(ExtendedProxyServlet.ja
 va:104)
 
 
 Is there a way to stop tomcat from throwing this error?

Don't use an invalid value for the domain when creating the cookie.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Rfc6265 cookies starting with a dot

[Peter Schroer]

This isn't possible because I'm writing some kind of proxy and I dont't have
any influence on the websites (and the cookies of course). It would be
possible to ignore invalid cookies if tomcat could be configured to do so.

Greetings Peter


-Ursprüngliche Nachricht-
Von: Mark Thomas [mailto:ma...@apache.org] 
Gesendet: Dienstag, 14. April 2015 16:02
An: Tomcat Users List
Betreff: Re: Rfc6265 cookies starting with a dot

On 14/04/2015 07:53, Peter Schroer wrote:
 Hello,
 
 I'm using tomcat 8.0.21 with the new Rfc6265 cookie processor. If 
 there are cookies starting with a dot I'm getting the following error:
 
 java.lang.IllegalArgumentException: An invalid domain [.db-app.de] was 
 specified for this cookie
 
 org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6
 265Coo
 kieProcessor.java:180)
 
 org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6
 265Coo
 kieProcessor.java:122)
 
 org.apache.catalina.connector.Response.generateCookieString(Response.j
 ava:95
 9)
 
 org.apache.catalina.connector.Response.addCookie(Response.java:907)
 
 org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.
 java:3
 92)
 
 org.esigate.servlet.impl.ResponseSender.sendResponse(ResponseSender.ja
 va:70)
 
 com.bahn.esiExtensions.ExtendedProxyServlet.doFilter(ExtendedProxyServ
 let.ja
 va:104)
 
 
 Is there a way to stop tomcat from throwing this error?

Don't use an invalid value for the domain when creating the cookie.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Rfc6265 cookies starting with a dot

[Peter Schroer]

Hello,

I'm using tomcat 8.0.21 with the new Rfc6265 cookie processor. If there are
cookies starting with a dot I'm getting the following error:

java.lang.IllegalArgumentException: An invalid domain [.db-app.de] was
specified for this cookie

org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6265Coo
kieProcessor.java:180)

org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265Coo
kieProcessor.java:122)

org.apache.catalina.connector.Response.generateCookieString(Response.java:95
9)

org.apache.catalina.connector.Response.addCookie(Response.java:907)

org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.java:3
92)

org.esigate.servlet.impl.ResponseSender.sendResponse(ResponseSender.java:70)

com.bahn.esiExtensions.ExtendedProxyServlet.doFilter(ExtendedProxyServlet.ja
va:104)


Is there a way to stop tomcat from throwing this error? Using the old cookie
processor is not an option because the old processor isn't able to handle
cookies containing umlauts.

Thanks in advance
Peter 

 

Re: How to enable cookies in Apache Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:54 PM, Pavel Yermolenko wrote:
 In my default browser (Chrome) the cookies are enabled, the proof
 is: the .jsp page is correctly displayed in browser. In the
 meantime I've tried to access to Manager App page from main page 
 http://localhost:8080/, but access were refused (I tried username
 = tomcat, password = tomcat). These default credentials are
 specified in tomcat-user.xml file. Where is a problem ?

The most common mistake when configuring access to the manager
application is forgetting to remove the !-- and -- comments from the
conf/tomcat-users.xml file.

Since you aren't using any super-secret credentials (tomcat/tomcat),
can you post the whole conf/tomcat-users.xml file?

It sounds like cookies are not the problem, here, but authentication
instead.

- -chris

 -Original Message- From: Caldarale, Charles R
 [mailto:chuck.caldar...@unisys.com] Sent: vendredi 27 mars 2015
 18:28 To: Tomcat Users List Subject: RE: How to enable cookies in
 Apache Tomcat
 
 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch] Subject: How
 to enable cookies in Apache Tomcat
 
 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
  opened page displays suggestions how to enable cookies in
 different
 browsers.
 
 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.
 
 If your browser is disabling cookies, you have to change the
 configuration in the browser - nothing Tomcat can do about that.
 
 - Chuck
 
 
 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
 PROPRIETARY MATERIAL and is thus for use only by the intended
 recipient. If you received this in error, please contact the sender
 and delete the e-mail and its attachments from all computers.
 
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 --- L'absence de virus dans ce courrier électronique a été vérifiée
 par le logiciel antivirus Avast. http://www.avast.com
 
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFZobAAoJEBzwKT+lPKRYnLUP/0DRv7I/yeriXYLwDYmr3q68
VI5s25p/gMgESo7iPEdrKhDrbKCQadbGqsLjwNGR8ASGfWJB+MiriHTe/n0GDbrp
MFZ2nqGN6i4QUnmT35esAgiHLRom8CZRoTDXjcuqZSpLO1nWZlm9+FNeN2LJo/aM
jWGL49R8XBzFTaVC7Abb/6gW1qmqiMS0iR2K8OU1v4qbxXI5Arp40rsahRbIIW2V
45YPNZva6SPxDyFxu9tCt/ZEG9nj44wduBzfyX+2ip8RC8TlG2EhDKGfnUCPH0A3
CMenIcEmTH1x6PauzIVLc5YUpRhabHl7FZCneZ91TZu4RsZ5qdWCuUhiBEnb6LdS
jKeIm6lvEIu+JB4+6CTEliBtZbAYuhJSEpYMYYVhmX55QlAqQADOUf1CaifnATGo
jBUiHK5ItMPJVh3/EJzEsk4maisNpwgp7SnEUg5gvyEpGfE+EcfQwnyhY9f51esl
0gVZ9qMj1FT1jG4IWI16wswf7eYBVqqoPYMDmssIc5j5+9dsZAMJvt7x9Mf6LgfX
cUIBPck9Kv5nuLthQ/vdMjTFc3g+BkTfVEYarOKfetCq0D7L0ZjlqkI9+3dTwXcZ
/WgqW9hxkhXa/U7pA0pq2rALDbsrbVKQCcvBwp6AdfRCMGQwTnACSTf0nXZAJt6a
E4qRlrRxpDkNP0TehE/c
=HGBC
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to enable cookies in Apache Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:07 PM, Pavel Yermolenko wrote:
 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
 browsers.
 
 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.

Do you mean session cookies, or just cookies in general?

Can you post some of the code you have already tried?

What tools are you using to see if cookies are working?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFY8sAAoJEBzwKT+lPKRY9qYP/j2HZS0FftKDV62UyNJ1vMsB
WlBa0NRNviqZLl+Ve9AYKrGtkfQw7O+fCUYE7/jn0z4kcuo/IhavsqRdD+KwPz5X
qwwGpcWuPA0beeJFGN5zeEjgNuMJBLKuF+7gxXF+flRE3NrSQtYHQCGYzELfHioZ
BobDR93OIKpDuAFVcaGVCiFubeFUtqHecixmMKTb/PAnTqAXwVugOXr4ihJkjn58
WGUOnA+oSO8H5DYMDA/FENpwt+q7ZsGL9Vi/eGBSLulP0YUbq893oIzJuSaannj0
9A6EvVIi0vUj0fhJo98+iYgwuX46VHTOuF5tyvxdoUyLI1d55PXPJvh/QQzR5sUM
5ayIeENuUDWxA2CuB0DegIy5GOR5WNQ4jCUa4vXwm31+IOR+4TXdQJj8q8GE1FVe
NuNE/WZSeuiIFq2vgVzMhkz5O8wkZdN7Ji3jVK26AA1Vcf7GPgM+8JEg6cdxMoK7
NCZl0knb8PzQSQuWl2SsbLeEOPHrZXRwQKF3l9Of6B59m8bZY/cw9tmtHbYCbQSw
ZKLWLvzP2K9fDC9r4UNvhhMQ0gPj7pvVzTLhlWpuqXxCaXeTzEEUThZmvmQDa+vU
ZLI5YK/OPfvdJbkvrg43nXTEUrCMMrfUVvnuC6F5p7O4HTfTHy2VUMBRKH5ov08F
NpWx0k/1LOlWG3QiAZMR
=s35h
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Caldarale, Charles R]

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch] 
 Subject: How to enable cookies in Apache Tomcat

 Trying to test jsp page in Apache Tomcat 8.0, I've met problems - opened
 page displays suggestions how to enable cookies in different browsers.

 Is there some option, allowing to setup/enable cookies in Apache Tomcat.

If your browser is disabling cookies, you have to change the configuration in 
the browser - nothing Tomcat can do about that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to enable cookies in Apache Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:35 PM, Pavel Yermolenko wrote:
 What I want is display correctly .jsp page that I execute in
 Eclipse. Ok, I forgot to precise that I work in Eclipse.
 
 In WebContent subfolder I created .jsp page (47kB) and try to test
 it with tomcat. What you mean saying Can you post some of the code
 ...  ? The content of .jsp ?

Yes, what does your .jsp file have in it?

 When I use my default browser (Chrome), the .jsp page is correctly
 visualized.

Is it possible that you have cookies disabled in the other browser
(not Chrome)?

- -chris

 -Original Message- From: Christopher Schultz
 [mailto:ch...@christopherschultz.net] Sent: vendredi 27 mars 2015
 18:11 To: Tomcat Users List Subject: Re: How to enable cookies in
 Apache Tomcat
 
 Pavel,
 
 On 3/27/15 1:07 PM, Pavel Yermolenko wrote:
 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
  opened page displays suggestions how to enable cookies in
 different browsers.
 
 Is there some option, allowing to setup/enable cookies in Apache
  Tomcat.
 
 Do you mean session cookies, or just cookies in general?
 
 Can you post some of the code you have already tried?
 
 What tools are you using to see if cookies are working?
 
 -chris
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 --- L'absence de virus dans ce courrier électronique a été vérifiée
 par le logiciel antivirus Avast. http://www.avast.com
 
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFZkiAAoJEBzwKT+lPKRYLGwP/Rtmv4rhSxH2ZC4DZ+fkR5s2
wzW3tkFP7LhdlUyzyEpMeBpCEmPC4B6240ug9xxhmx0a9rGMiOAMM91ZWIjZ6kbZ
699qDDUOBLKnz6kMkkmAQX5pTC2pMEO3zb0iHPrw6m1Ex2iuUM1eRFtuqt/0q4r4
GQy2PTK6lmFKDE6ubPgoGw9Yp06bXcQ08anlM/ChwAuW97glCJWV+aRMXxLjGrVi
obkPIoBGPPKGdODecQk5RvL7BmvQ6Dzn2vUl2qBXr5bLh5g1RA1g69sG55L0SLyC
qptbJT3gl59gyNfG+yPVW++GqPAal/Ou0APaqQk/NuscNjgtmQnWU/zPRKLmbOTa
0ICcphPOVPL22u6+r5G4UprVQykiL066Wky1n+632HO4p18LgOGNVk8I3YEXDL8o
DNyxS6++6n4VyBvLFKqsie6YSFOkyqmYpzFDTIm19xBNGh0M4uxlIh4bFthnw9Fd
RJgkPpqdZgB1hDNvV5ocS5kGFVSkN4staarUNBcImL3BAl8LjWFQ71gAXKXQzmrt
UN+hqC1kHeA6raKFk9nMak1+arMZnOZ5ppox9k9KN6QA/FKGq5u5hBhq2CmqiNiz
d8e5yKsRko3d0V2tti4Wkhu4UFisjcUl7/lcHwm0nUpKlDCnTTUlWtgNP3HzGeAI
SxljuWrgyfEz2XUNxeQV
=GbDS
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Hello Chuck,

In my default browser (Chrome) the cookies are enabled, the proof is: the
.jsp page is correctly displayed in browser.
In the meantime I've tried to access to Manager App page from main page
http://localhost:8080/, but access were refused (I tried username  =
tomcat, password = tomcat).
These default credentials are specified in tomcat-user.xml file. Where is a
problem ?

Thanks

Pavel


-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: vendredi 27 mars 2015 18:28
To: Tomcat Users List
Subject: RE: How to enable cookies in Apache Tomcat

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch]
 Subject: How to enable cookies in Apache Tomcat

 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
browsers.

 Is there some option, allowing to setup/enable cookies in Apache Tomcat.

If your browser is disabling cookies, you have to change the configuration
in the browser - nothing Tomcat can do about that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Hello,



Hello,



Trying to test jsp page in Apache Tomcat 8.0, I've met problems - opened
page displays suggestions how to enable cookies in different browsers.



Is there some option, allowing to setup/enable cookies in Apache Tomcat.



Thanks in advance



Pavel



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Hello Christopher,

Thank you for response.
What I want is display correctly .jsp page that I execute in Eclipse.
Ok, I forgot to precise that I work in Eclipse.

In WebContent subfolder I created .jsp page (47kB) and try to test it with 
tomcat.
What you mean saying Can you post some of the code ...  ?
The content of .jsp ?

When I use my default browser (Chrome), the .jsp page is correctly visualized.

Regards

Pavel

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: vendredi 27 mars 2015 18:11
To: Tomcat Users List
Subject: Re: How to enable cookies in Apache Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:07 PM, Pavel Yermolenko wrote:
 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
 browsers.

 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.

Do you mean session cookies, or just cookies in general?

Can you post some of the code you have already tried?

What tools are you using to see if cookies are working?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFY8sAAoJEBzwKT+lPKRY9qYP/j2HZS0FftKDV62UyNJ1vMsB
WlBa0NRNviqZLl+Ve9AYKrGtkfQw7O+fCUYE7/jn0z4kcuo/IhavsqRdD+KwPz5X
qwwGpcWuPA0beeJFGN5zeEjgNuMJBLKuF+7gxXF+flRE3NrSQtYHQCGYzELfHioZ
BobDR93OIKpDuAFVcaGVCiFubeFUtqHecixmMKTb/PAnTqAXwVugOXr4ihJkjn58
WGUOnA+oSO8H5DYMDA/FENpwt+q7ZsGL9Vi/eGBSLulP0YUbq893oIzJuSaannj0
9A6EvVIi0vUj0fhJo98+iYgwuX46VHTOuF5tyvxdoUyLI1d55PXPJvh/QQzR5sUM
5ayIeENuUDWxA2CuB0DegIy5GOR5WNQ4jCUa4vXwm31+IOR+4TXdQJj8q8GE1FVe
NuNE/WZSeuiIFq2vgVzMhkz5O8wkZdN7Ji3jVK26AA1Vcf7GPgM+8JEg6cdxMoK7
NCZl0knb8PzQSQuWl2SsbLeEOPHrZXRwQKF3l9Of6B59m8bZY/cw9tmtHbYCbQSw
ZKLWLvzP2K9fDC9r4UNvhhMQ0gPj7pvVzTLhlWpuqXxCaXeTzEEUThZmvmQDa+vU
ZLI5YK/OPfvdJbkvrg43nXTEUrCMMrfUVvnuC6F5p7O4HTfTHy2VUMBRKH5ov08F
NpWx0k/1LOlWG3QiAZMR
=s35h
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to enable cookies in Apache Tomcat

[André Warnier]

Pavel Yermolenko wrote:

Hello Chuck,

In my default browser (Chrome) the cookies are enabled, the proof is: the
.jsp page is correctly displayed in browser.
In the meantime I've tried to access to Manager App page from main page
http://localhost:8080/, but access were refused (I tried username  =
tomcat, password = tomcat).
These default credentials are specified in tomcat-user.xml file. Where is a
problem ?


That in the default tomcat-users.xml file, they are commented-out ?
Look for enclosing !-- ... -- signs.
Those indicate that anything in-between is a comment.



Thanks

Pavel


-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: vendredi 27 mars 2015 18:28

To: Tomcat Users List
Subject: RE: How to enable cookies in Apache Tomcat


From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch]
Subject: How to enable cookies in Apache Tomcat


Trying to test jsp page in Apache Tomcat 8.0, I've met problems - 
opened page displays suggestions how to enable cookies in different

browsers.


Is there some option, allowing to setup/enable cookies in Apache Tomcat.


If your browser is disabling cookies, you have to change the configuration
in the browser - nothing Tomcat can do about that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Caldarale, Charles R]

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch] 
 Subject: RE: How to enable cookies in Apache Tomcat

 In the meantime I've tried to access to Manager App page from main page

This is a different issue, so should be discussed in a different thread.  Read 
this first:
http://www.catb.org/~esr/faqs/smart-questions.html

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Chris,

Indeed, it was the case - after checking 2 other browsers (IE and Mozilla) I 
discovered that cookies weren't enable there.
I enabled them in both (IE and Mozilla), but nothing changed in Eclipse when I 
run .jsp page.

I can attach .jsp file (47kB), but not sure that it's supported by forum rules ?

Regards

Pavel

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: vendredi 27 mars 2015 18:54
To: Tomcat Users List
Subject: Re: How to enable cookies in Apache Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:35 PM, Pavel Yermolenko wrote:
 What I want is display correctly .jsp page that I execute in Eclipse.
 Ok, I forgot to precise that I work in Eclipse.

 In WebContent subfolder I created .jsp page (47kB) and try to test it
 with tomcat. What you mean saying Can you post some of the code ... 
 ? The content of .jsp ?

Yes, what does your .jsp file have in it?

 When I use my default browser (Chrome), the .jsp page is correctly
 visualized.

Is it possible that you have cookies disabled in the other browser (not Chrome)?

- -chris

 -Original Message- From: Christopher Schultz
 [mailto:ch...@christopherschultz.net] Sent: vendredi 27 mars 2015
 18:11 To: Tomcat Users List Subject: Re: How to enable cookies in
 Apache Tomcat

 Pavel,

 On 3/27/15 1:07 PM, Pavel Yermolenko wrote:
 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
 browsers.

 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.

 Do you mean session cookies, or just cookies in general?

 Can you post some of the code you have already tried?

 What tools are you using to see if cookies are working?

 -chris

 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 --- L'absence de virus dans ce courrier électronique a été vérifiée
 par le logiciel antivirus Avast. http://www.avast.com


 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFZkiAAoJEBzwKT+lPKRYLGwP/Rtmv4rhSxH2ZC4DZ+fkR5s2
wzW3tkFP7LhdlUyzyEpMeBpCEmPC4B6240ug9xxhmx0a9rGMiOAMM91ZWIjZ6kbZ
699qDDUOBLKnz6kMkkmAQX5pTC2pMEO3zb0iHPrw6m1Ex2iuUM1eRFtuqt/0q4r4
GQy2PTK6lmFKDE6ubPgoGw9Yp06bXcQ08anlM/ChwAuW97glCJWV+aRMXxLjGrVi
obkPIoBGPPKGdODecQk5RvL7BmvQ6Dzn2vUl2qBXr5bLh5g1RA1g69sG55L0SLyC
qptbJT3gl59gyNfG+yPVW++GqPAal/Ou0APaqQk/NuscNjgtmQnWU/zPRKLmbOTa
0ICcphPOVPL22u6+r5G4UprVQykiL066Wky1n+632HO4p18LgOGNVk8I3YEXDL8o
DNyxS6++6n4VyBvLFKqsie6YSFOkyqmYpzFDTIm19xBNGh0M4uxlIh4bFthnw9Fd
RJgkPpqdZgB1hDNvV5ocS5kGFVSkN4staarUNBcImL3BAl8LjWFQ71gAXKXQzmrt
UN+hqC1kHeA6raKFk9nMak1+arMZnOZ5ppox9k9KN6QA/FKGq5u5hBhq2CmqiNiz
d8e5yKsRko3d0V2tti4Wkhu4UFisjcUl7/lcHwm0nUpKlDCnTTUlWtgNP3HzGeAI
SxljuWrgyfEz2XUNxeQV
=GbDS
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to enable cookies in Apache Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 2:29 PM, Pavel Yermolenko wrote:
 Indeed, I forgot about comments ... but after removing them the
 issue persists - the pair tomcat/tomcat (for username/password)
 still doesn't work.

Hmm. Can you post the full contents of the conf/tomcat-users.xml file?

Did you restart Tomcat after modifying that file? It does not
auto-reload when the file changes.

 Concerning authentication, probably I have a reason - but how to 
 check if this is actually the case ?

Well... if you can't log into the manager application, then
authentication certainly is a problem :)

 The final goal of my demarche - automatize articles downloading
 from some portal: page is analyzed, links to .pdf files found, and
 then special classes are used for downloading.

That sounds like an interesting project, but let's focus on getting
access to the Manager application, first. As Chuck suggested in
another reply, please try to keep posts on a single topic. Feel free
to start a new mailing-list thread with a separate question. (But
again, let's take care of the Manager-access problem, first).

 If I succeed to properly run jsp page on tomcat, probably there is
 a technic allowing to access running result from java code.

Aah, so you'd like to evaluate a JSP page and use the resulting
content in some kind of other message? That's definitely a different
kind of question that you should post separately (just start a new
message to the list; don't do a REPLY to this thread).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFaQkAAoJEBzwKT+lPKRYK10P/2wq+6NH7dVoI6SViTk/tEHQ
Ncuj9IOUiYMiJd7x0YVz4TmcSwzIsLmGclLHb1Ts9pR1tgc+oOVKDFuS/xC5ezQ/
mnVZym9WaglpP0z0H2a6nLydCAT6qZUqG/UxfhfHZh2xXxgZjUg7bkIZQcCEBC/S
hEwtFSLXdxD1uUhSYmxGoLP7Nh3UxCCuCNRFK4qYW2WVn8rVjxU9w29LLY37HdAu
S/ZdHr1ChiwhnFNVdLcL/XWSEwheV1kwj5i8eoRTxnUrj3R8PZqHP6W7+A86EmgP
lndRcCHpC/nQIjkz6A3gSprh9gE2quswxQuOXPrwoaWkvJ/q6WOJtaaAd3N2ron+
xcgEy/nSL7WgQ+W2LCetiSBs7SbAf5p6kE3TUAi+VAUmEj5nvOy1XHB0xFJMkh+y
t3THaXyTt2AEduh6W6jUTxbrO14j1UVSg9ly2aTo2HSXuSCPAKUlFQtdjsQIuYHG
93/r9B4+xqKSz7Lms0WfgEPhJO5NwSrAz2Ac+/09hNeGifxgHSOLT5naCftS1KNe
OFI1lsWifD/2F6+U3cY29sVI/LQpMrts5KdN7CSy6AeRXuQj/KIQVvNCFw79m6H0
0E7x8lKSIEyC8YbgguO04eVrFHmoqgDkCEsQUHbJbJsmp7/iJMcASWoLzli0uTB4
8ibEBn5OyvokxdF+6uD1
=K8ar
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

In attachment I've put the content of .jsp

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: vendredi 27 mars 2015 18:58
To: Tomcat Users List
Subject: Re: How to enable cookies in Apache Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:54 PM, Pavel Yermolenko wrote:
 In my default browser (Chrome) the cookies are enabled, the proof
 is: the .jsp page is correctly displayed in browser. In the meantime
 I've tried to access to Manager App page from main page
 http://localhost:8080/, but access were refused (I tried username =
 tomcat, password = tomcat). These default credentials are
 specified in tomcat-user.xml file. Where is a problem ?

The most common mistake when configuring access to the manager application is 
forgetting to remove the !-- and -- comments from the conf/tomcat-users.xml 
file.

Since you aren't using any super-secret credentials (tomcat/tomcat), can you 
post the whole conf/tomcat-users.xml file?

It sounds like cookies are not the problem, here, but authentication instead.

- -chris

 -Original Message- From: Caldarale, Charles R
 [mailto:chuck.caldar...@unisys.com] Sent: vendredi 27 mars 2015
 18:28 To: Tomcat Users List Subject: RE: How to enable cookies in
 Apache Tomcat

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch] Subject: How to
 enable cookies in Apache Tomcat

 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
 browsers.

 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.

 If your browser is disabling cookies, you have to change the
 configuration in the browser - nothing Tomcat can do about that.

 - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
 PROPRIETARY MATERIAL and is thus for use only by the intended
 recipient. If you received this in error, please contact the sender
 and delete the e-mail and its attachments from all computers.


 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 --- L'absence de virus dans ce courrier électronique a été vérifiée
 par le logiciel antivirus Avast. http://www.avast.com


 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFZobAAoJEBzwKT+lPKRYnLUP/0DRv7I/yeriXYLwDYmr3q68
VI5s25p/gMgESo7iPEdrKhDrbKCQadbGqsLjwNGR8ASGfWJB+MiriHTe/n0GDbrp
MFZ2nqGN6i4QUnmT35esAgiHLRom8CZRoTDXjcuqZSpLO1nWZlm9+FNeN2LJo/aM
jWGL49R8XBzFTaVC7Abb/6gW1qmqiMS0iR2K8OU1v4qbxXI5Arp40rsahRbIIW2V
45YPNZva6SPxDyFxu9tCt/ZEG9nj44wduBzfyX+2ip8RC8TlG2EhDKGfnUCPH0A3
CMenIcEmTH1x6PauzIVLc5YUpRhabHl7FZCneZ91TZu4RsZ5qdWCuUhiBEnb6LdS
jKeIm6lvEIu+JB4+6CTEliBtZbAYuhJSEpYMYYVhmX55QlAqQADOUf1CaifnATGo
jBUiHK5ItMPJVh3/EJzEsk4maisNpwgp7SnEUg5gvyEpGfE+EcfQwnyhY9f51esl
0gVZ9qMj1FT1jG4IWI16wswf7eYBVqqoPYMDmssIc5j5+9dsZAMJvt7x9Mf6LgfX
cUIBPck9Kv5nuLthQ/vdMjTFc3g+BkTfVEYarOKfetCq0D7L0ZjlqkI9+3dTwXcZ
/WgqW9hxkhXa/U7pA0pq2rALDbsrbVKQCcvBwp6AdfRCMGQwTnACSTf0nXZAJt6a
E4qRlrRxpDkNP0TehE/c
=HGBC
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Chris,

Indeed, I forgot about comments ... but after removing them the issue persists 
- the pair tomcat/tomcat (for username/password) still doesn't work.
Concerning authentication, probably I have a reason - but how to check if this 
is actually the case ?

The final goal of my demarche - automatize articles downloading from some 
portal: page is analyzed, links to .pdf files found, and then special classes 
are used for downloading.
Initially I realized such approach in C# and it worked properly with another 
portal with simple pages.

In actual portal (with jsp pages) this approach no more works. So I try to find 
some solution with Java/tomcat.
If I succeed to properly run jsp page on tomcat, probably there is a technic 
allowing to access running result from java code.

Regards

Pavel.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: vendredi 27 mars 2015 18:58
To: Tomcat Users List
Subject: Re: How to enable cookies in Apache Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pavel,

On 3/27/15 1:54 PM, Pavel Yermolenko wrote:
 In my default browser (Chrome) the cookies are enabled, the proof
 is: the .jsp page is correctly displayed in browser. In the meantime
 I've tried to access to Manager App page from main page
 http://localhost:8080/, but access were refused (I tried username =
 tomcat, password = tomcat). These default credentials are
 specified in tomcat-user.xml file. Where is a problem ?

The most common mistake when configuring access to the manager application is 
forgetting to remove the !-- and -- comments from the conf/tomcat-users.xml 
file.

Since you aren't using any super-secret credentials (tomcat/tomcat), can you 
post the whole conf/tomcat-users.xml file?

It sounds like cookies are not the problem, here, but authentication instead.

- -chris

 -Original Message- From: Caldarale, Charles R
 [mailto:chuck.caldar...@unisys.com] Sent: vendredi 27 mars 2015
 18:28 To: Tomcat Users List Subject: RE: How to enable cookies in
 Apache Tomcat

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch] Subject: How to
 enable cookies in Apache Tomcat

 Trying to test jsp page in Apache Tomcat 8.0, I've met problems -
 opened page displays suggestions how to enable cookies in different
 browsers.

 Is there some option, allowing to setup/enable cookies in Apache
 Tomcat.

 If your browser is disabling cookies, you have to change the
 configuration in the browser - nothing Tomcat can do about that.

 - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
 PROPRIETARY MATERIAL and is thus for use only by the intended
 recipient. If you received this in error, please contact the sender
 and delete the e-mail and its attachments from all computers.


 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 --- L'absence de virus dans ce courrier électronique a été vérifiée
 par le logiciel antivirus Avast. http://www.avast.com


 -


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVFZobAAoJEBzwKT+lPKRYnLUP/0DRv7I/yeriXYLwDYmr3q68
VI5s25p/gMgESo7iPEdrKhDrbKCQadbGqsLjwNGR8ASGfWJB+MiriHTe/n0GDbrp
MFZ2nqGN6i4QUnmT35esAgiHLRom8CZRoTDXjcuqZSpLO1nWZlm9+FNeN2LJo/aM
jWGL49R8XBzFTaVC7Abb/6gW1qmqiMS0iR2K8OU1v4qbxXI5Arp40rsahRbIIW2V
45YPNZva6SPxDyFxu9tCt/ZEG9nj44wduBzfyX+2ip8RC8TlG2EhDKGfnUCPH0A3
CMenIcEmTH1x6PauzIVLc5YUpRhabHl7FZCneZ91TZu4RsZ5qdWCuUhiBEnb6LdS
jKeIm6lvEIu+JB4+6CTEliBtZbAYuhJSEpYMYYVhmX55QlAqQADOUf1CaifnATGo
jBUiHK5ItMPJVh3/EJzEsk4maisNpwgp7SnEUg5gvyEpGfE+EcfQwnyhY9f51esl
0gVZ9qMj1FT1jG4IWI16wswf7eYBVqqoPYMDmssIc5j5+9dsZAMJvt7x9Mf6LgfX
cUIBPck9Kv5nuLthQ/vdMjTFc3g+BkTfVEYarOKfetCq0D7L0ZjlqkI9+3dTwXcZ
/WgqW9hxkhXa/U7pA0pq2rALDbsrbVKQCcvBwp6AdfRCMGQwTnACSTf0nXZAJt6a
E4qRlrRxpDkNP0TehE/c
=HGBC
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to enable cookies in Apache Tomcat

[Pavel Yermolenko]

Ok Chuck, I'm sorry.
I'll not repeat this error.

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: vendredi 27 mars 2015 19:01
To: Tomcat Users List
Subject: RE: How to enable cookies in Apache Tomcat

 From: Pavel Yermolenko [mailto:py.oh...@sunrise.ch]
 Subject: RE: How to enable cookies in Apache Tomcat

 In the meantime I've tried to access to Manager App page from main page

This is a different issue, so should be discussed in a different thread.
Read this first:
http://www.catb.org/~esr/faqs/smart-questions.html

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Single Signon without Cookies

[Brian Burch]

On 10/12/13 18:02, Mark Thomas wrote:

On 10/12/2013 17:13, Brian Burch wrote:

Some background first: I made a lot of changes to the Authenticator test
classes some time ago. That led to changes to some of the Authenticator
classes. The test classes are basically in pairs - with and without
SSO.

I decided to revisit the entire test suite, trying to make them more
self-consistent and self-documenting. I hoped to remove redundant tests
and perhaps add some missing edge cases at the same time.

I started work on TestSSOnonLoginAndBasicAuthenticator and found a test
that ended successfully, but for the wrong reason! (I take the blame.)

As I changed the test to do what it claimed, I discovered that
org.apache.catalina.connector.Response.encodeURL (implements
javax.servlet.http.HttpServletResponse) has logic to add the session ID
to the url in the jsessionid parameter, but there is nothing to add the
SSO session ID.

I decided to RTFM... Single Signon is described briefly in the Servlet
Spec, but is not defined. Tomcat implements SSO as a Valve. It is
described in the tomcat docs Reference section,

docs/config/host.html#Single Sign On

... which has six bullet points, the last of which says:

The Single Sign On feature utilizes HTTP cookies to transmit a token
that associates each request with the saved user identity, so it can
only be utilized in client environments that support cookies.

I had always thought encoded url's were equally acceptable, but I was
mistaken. The documentation is clear and consistent with the
implementation.

I need to fix my faulty unit test(s), but before I do any work I would
like to ask whether the restriction SSO is only available to clients
that accept cookies is reasonable and necessary. My initial thought is
that it wouldn't be too hard to support SSO within encodeURL (the real
work is done in Response.toEncoded).

WDYT?


I think that session IDs in URLs are a bad idea because of the security
implications. They are only supported because the Servlet spec says they
have to be. Given that there is no spec requirement to support SSO
session tracking via URLs I don't think we should.


I didn't want to put forward my own opinion until I heard your thoughts.

I basically agree with Martin G in this case - anyone who cares about 
authentication (or any other kind of) security ought to be using the 
cloak of SSL, in which case the inside security isn't so important. As 
he points out, unwrapping the SSO session ID from a cookie isn't that 
difficult compared to reading it off the url in the HTTP response.


Nevertheless, we haven't had any it doesn't work or why do I have to 
use cookies questions on the users list, so there can't be much need 
for the feature in the real world. I'll review the unit tests and make 
sure we only have cases that work properly under the existing 
implementation.


Thanks,

Brian


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Single Signon without Cookies

[selvakumar netaji]

Hi Brian,

Can you send us some sample unit tests if it doesn't violate any laws or
infringements.

Re: Single Signon without Cookies

[Brian Burch]

On 11/12/13 16:47, selvakumar netaji wrote:

Hi Brian,

Can you send us some sample unit tests if it doesn't violate any laws or
infringements.


Like tomcat itself, the unit tests are open source. The tests are all in 
the tc7 and tc8 repositories! Just do a svn checkout or browse them online.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Single Signon without Cookies

[Brian Burch]

Some background first: I made a lot of changes to the Authenticator test 
classes some time ago. That led to changes to some of the Authenticator 
classes. The test classes are basically in pairs - with and without SSO.


I decided to revisit the entire test suite, trying to make them more 
self-consistent and self-documenting. I hoped to remove redundant tests 
and perhaps add some missing edge cases at the same time.


I started work on TestSSOnonLoginAndBasicAuthenticator and found a test 
that ended successfully, but for the wrong reason! (I take the blame.)


As I changed the test to do what it claimed, I discovered that 
org.apache.catalina.connector.Response.encodeURL (implements 
javax.servlet.http.HttpServletResponse) has logic to add the session ID 
to the url in the jsessionid parameter, but there is nothing to add the 
SSO session ID.


I decided to RTFM... Single Signon is described briefly in the Servlet 
Spec, but is not defined. Tomcat implements SSO as a Valve. It is 
described in the tomcat docs Reference section,


docs/config/host.html#Single Sign On

... which has six bullet points, the last of which says:

The Single Sign On feature utilizes HTTP cookies to transmit a token 
that associates each request with the saved user identity, so it can 
only be utilized in client environments that support cookies.


I had always thought encoded url's were equally acceptable, but I was 
mistaken. The documentation is clear and consistent with the implementation.


I need to fix my faulty unit test(s), but before I do any work I would 
like to ask whether the restriction SSO is only available to clients 
that accept cookies is reasonable and necessary. My initial thought is 
that it wouldn't be too hard to support SSO within encodeURL (the real 
work is done in Response.toEncoded).


WDYT?

Regards,

Brian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Single Signon without Cookies

[Mark Thomas]

On 10/12/2013 17:13, Brian Burch wrote:
 Some background first: I made a lot of changes to the Authenticator test
 classes some time ago. That led to changes to some of the Authenticator
 classes. The test classes are basically in pairs - with and without
 SSO.
 
 I decided to revisit the entire test suite, trying to make them more
 self-consistent and self-documenting. I hoped to remove redundant tests
 and perhaps add some missing edge cases at the same time.
 
 I started work on TestSSOnonLoginAndBasicAuthenticator and found a test
 that ended successfully, but for the wrong reason! (I take the blame.)
 
 As I changed the test to do what it claimed, I discovered that
 org.apache.catalina.connector.Response.encodeURL (implements
 javax.servlet.http.HttpServletResponse) has logic to add the session ID
 to the url in the jsessionid parameter, but there is nothing to add the
 SSO session ID.
 
 I decided to RTFM... Single Signon is described briefly in the Servlet
 Spec, but is not defined. Tomcat implements SSO as a Valve. It is
 described in the tomcat docs Reference section,
 
 docs/config/host.html#Single Sign On
 
 ... which has six bullet points, the last of which says:
 
 The Single Sign On feature utilizes HTTP cookies to transmit a token
 that associates each request with the saved user identity, so it can
 only be utilized in client environments that support cookies.
 
 I had always thought encoded url's were equally acceptable, but I was
 mistaken. The documentation is clear and consistent with the
 implementation.
 
 I need to fix my faulty unit test(s), but before I do any work I would
 like to ask whether the restriction SSO is only available to clients
 that accept cookies is reasonable and necessary. My initial thought is
 that it wouldn't be too hard to support SSO within encodeURL (the real
 work is done in Response.toEncoded).
 
 WDYT?

I think that session IDs in URLs are a bad idea because of the security
implications. They are only supported because the Servlet spec says they
have to be. Given that there is no spec requirement to support SSO
session tracking via URLs I don't think we should.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: with useHttpOnly=true my browser could access cookies through javascript.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sush,

On 11/24/13, 5:05 AM, sush3152 . wrote:
 Thanks Chris.This is really useful. As you suggested,this time i
 let tomcat to manage the sessionID by removing 
 response.setHeader(SET-COOKIE, JSESSIONID= + sessionid.
 from the code.I could see the below result Set-Cookie:
 JSESSIONID=01D4A20F51FCE8F8401B47999524D8AB; 
 Path=/UserHttpOnlyTest/; Secure; HttpOnly
 
 I have one more question to the same context,is there a way to
 enable the httponly to the non-container managed cookies other than
 programatically?

No. It's not appropriate for the container to interfere with cookies
added to a response by the application.

 Adding the below lines in my application web.xml doenst have an
 impact on the header session-config cookie-config 
 http-onlytrue/http-only /cookie-config session-config

Nor should it. The above only affects the JSESSIONID cookie, and only
if Tomcat creates the cookie.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSk1jqAAoJEBzwKT+lPKRYV2EQAKUwxv9cTQiBeGellpU/ZZyn
4HU/k1ThQD9tNSszk7B1sBncVCn3aclpUdXN3waABA93J8K6vSM9yQcmXCZsPSPz
67kcykEUHJzHxP7bSjBaomquiDvE5V/91OzXg35pLcNDAIBTdCepIcM+7u0jT5Th
wl5DJ6S8nx/WfygKIbMj0vt2hiQjxTfhuboUwFIs+XAsd6l1x+zbiESaPNIGKaEG
+0gvft/FwRr9XUjOk1W46jgLgurz197kIaj57CRyjQaazA1bqWxgyDXL6oqb7JHO
cuoyPKIk37k37+0V8cC+LSjH8pP2DqRocM2pXlMgxaDZXcizBLU0CfSF56PUesNk
WfEEBlN2CxzeKQcqflhH1lqH9a/ayeld2xaF2aNJoHNLm6h0H4qKjPWWGpboFPAQ
aCqDRFua71Uw3d5Ezj/vRmM7Zvk3DJex4y4HUeMQYW9GTeusshPsDSfCnLFkOQUa
0xqQmYETVbg+lvNUQSqJl5XGIC6gIRo9iDgioj1Z9a5jAaRMKSCPI0OwnJ4k9cRV
XalY3ej9htfVIlIV7ALICENervaZ5kdzHTtUWpPi4mdUJaa0iaBcMc7F8vuQy7aU
VhpMeYTi5/SRe6Bifd8ENwQLC83qNxMmD1baTLerApPhdjTVm9rxsfwDsMTFSS34
l6ZP+eeX7lJhdQRXKR6o
=fQ5w
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: with useHttpOnly=true my browser could access cookies through javascript.

[sush3152 .]

Thanks Chris.This is really useful.
As you suggested,this time i let tomcat to manage the sessionID by removing
response.setHeader(SET-COOKIE, JSESSIONID= + sessionid. from the
code.I could see the below result
Set-Cookie: JSESSIONID=01D4A20F51FCE8F8401B47999524D8AB;
Path=/UserHttpOnlyTest/; Secure; HttpOnly

I have one more question to the same context,is there a way to enable the
httponly to the non-container managed cookies other than programatically?

Adding the below lines in my application web.xml doenst have an impact on
the header
session-config
cookie-config
http-onlytrue/http-only
/cookie-config
session-config
I got the cookie header  as below,missing httponly details
Set-Cookie: url=testing userHttpOnly; Version=1; Max-Age=3600;
Expires=Sun, 24-Nov-2013 08:37:37 GMT
Set-Cookie: Mr.x=testing the cookie; Version=1

Thanks in advance.


On Fri, Nov 22, 2013 at 12:54 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sush,

 On 11/21/13, 1:54 PM, sush3152 . wrote:
  Hi,i have the below details about the problem. Please go though it
  and let me know if i am making any mistakes.
 
  Environmnent Tomcat7

 Exactly which version of Tomcat 7?

  Windows7/Centos6.3 64bit jdk 7 Mozilla firefox 25.0.1
 
 
  CATALINA_HOME/conf/context.xml Context useHttpOnly=true/
  WatchedResourceWEB-INF/web.xml/WatchedResource /Context

 You probably should not have modified this file (conf/context.xml).
 Instead, you should be using a META-INF/context.xml file in your web
 application. Note that true is the default value for this
 configuration setting, so you should not have to set it at all.

 Perhaps you have useHttpOnly=false in your web application's
 context.xml and it is overriding?

  Since i am using tomcat7 i dont think i need to configure
  useHttpOnly=true explicitly.

 You should not have to do so.

  Java code which generates the cookie
 
  response.setContentType(text/html); PrintWriter pw =
  response.getWriter(); Cookie cookie = new Cookie(url,testing
  userHttpOnly); Cookie cookie1 = new Cookie(Mr.x,testing the
  cookie); cookie.setMaxAge(60*60); //1 hour String sessionid =
  request.getSession().getId(); String contextPath =
  request.getContextPath(); response.setHeader(SET-COOKIE,
  JSESSIONID= + sessionid + ; Path= + contextPath);
  response.addCookie(cookie); response.addCookie(cookie1);
  pw.println(Cookies created);

 Well, of course that code will not enable HttpOnly: you are creating
 the cookie yourself by emitting the Set-Cookie header. If you had
 let Tomcat create your JSESSIONID cookie for you, it would have
 included the HttpOnly flag.

  With the below lines,i could see the ;HttpOnly along with the
  cookie information in the http header and the same java script code
  return undefined which is what i wanted.
  response.setHeader(SET-COOKIE, JSESSIONID= + sessionid + ;
  Path= + contextPath + ; HttpOnly );
 
  Conclusion : As per my understanding the the cookie should be
  HttpOnly with the way i configured my context.xml.No java code is
  required for that.But this is not happening for me.Please let me
  know if i missed anything

 Tomcat will not intercept your cookies and correct them to be
 HttpOnly. That would be a violation of the servlet specification.
 Tomcat will protect *its own* session cookie(s) by using the
 HttpOnly flag, not just any cookie you happen to send back to the
 client.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSjl4KAAoJEBzwKT+lPKRYoscQAJKTio8E9EeSSi6XkN3ZNv1o
 ph0wpLYvWAKS9QiiXBmitK4ULFAxtJ1jH0cFqF84LxImwRN50jaS63AiFWZIwsiy
 c28c9lTyCBcv5fNbRgW7qR2jPr+iilUjUbdt1KyDNoHmzecvrXizc+EXOxjeRQfG
 Weww6V8YQH/QaQacddPq4rLsyibQl/YQ1dS5I+LAFPBEIilnKe8sqPUude9CrA86
 l+vH6f6tbHWrMotE260ORFZCqs7LqhbjvWu0ZqT9pHuD5slK0a7HQvGH/GtCC8Dc
 NENHF5lOshRMfoVrfaCgvx+1LPAblHePqUM/ZBBG9ZbXBrc5LihHKSktI/XVt3WB
 NbThnKMqYnHJkotbe4znUfuDSokCEW/xEsnStpqUuhr1L6VjBHZ02ME0O2SfPglM
 z8FNh7Gf92GZu2TOEesVXeIivO5T7c478x0yxWtL2F5230z1WHlUxnRhYlPbgjQz
 WuIK8wp0IBsXSmd+leog1E2GAnJL3GkefxWWam4j9w+Xf4A1lfk1UYh1oCgD22zI
 +IYMZMuKImYo0MZ9SkWCsVYBsakRsuoh/VH3/QMTB1QCIndDSGfcahcX0NT5R6vR
 winJpj5h8IPMnM/nQEr/hsuPBUZ8EkhdsMd2YeclRBI5HidNqA6hhUN2QPBS9Yj0
 5Bho1uInzvBd6QekswJj
 =YBXm
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

with useHttpOnly=true my browser could access cookies through javascript.

[sush3152 .]

Hi,i have the below details about the problem.Please go though it and let
me know if i am making any mistakes.

Environmnent
Tomcat7
Windows7/Centos6.3 64bit
jdk 7
Mozilla firefox 25.0.1


CATALINA_HOME/conf/context.xml
Context useHttpOnly=true/
WatchedResourceWEB-INF/web.xml/WatchedResource
/Context
Since i am using tomcat7 i dont think i need to configure
useHttpOnly=true explicitly.

Java code which generates the cookie

response.setContentType(text/html);
PrintWriter pw = response.getWriter();
Cookie cookie = new Cookie(url,testing userHttpOnly);
Cookie cookie1 = new Cookie(Mr.x,testing the cookie);
cookie.setMaxAge(60*60); //1 hour
String sessionid = request.getSession().getId();
String contextPath = request.getContextPath();
response.setHeader(SET-COOKIE, JSESSIONID= + sessionid
+ ; Path= + contextPath);
response.addCookie(cookie);
response.addCookie(cookie1);
pw.println(Cookies created);

When i verified http header,i am able to see the cookie values as
Set-Cookie: JSESSIONID=660BA8ABDC53B0B91AC53A533410FB2B;
Path=/UserHttpOnlyTest
Set-Cookie: url=testing userHttpOnly; Version=1; Max-Age=3600;
Expires=Thu, 21-Nov-2013 19:30:14 GMT
Set-Cookie: Mr.x=testing the cookie; Version=1
And
My browser could access the cookie using  document.cookie and i could
alert the cookie values.

With the below lines,i could see the ;HttpOnly along with the cookie
information in the http header and the same java script code return
undefined which is what i wanted.
response.setHeader(SET-COOKIE, JSESSIONID= + sessionid
 + ; Path= + contextPath + ; HttpOnly );

Conclusion : As per my understanding the the cookie should be HttpOnly with
the way i configured my context.xml.No java code is required for that.But
this is not happening for me.Please let me know if i missed anything

Thanks in advance.

Re: with useHttpOnly=true my browser could access cookies through javascript.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sush,

On 11/21/13, 1:54 PM, sush3152 . wrote:
 Hi,i have the below details about the problem. Please go though it
 and let me know if i am making any mistakes.
 
 Environmnent Tomcat7

Exactly which version of Tomcat 7?

 Windows7/Centos6.3 64bit jdk 7 Mozilla firefox 25.0.1
 
 
 CATALINA_HOME/conf/context.xml Context useHttpOnly=true/ 
 WatchedResourceWEB-INF/web.xml/WatchedResource /Context

You probably should not have modified this file (conf/context.xml).
Instead, you should be using a META-INF/context.xml file in your web
application. Note that true is the default value for this
configuration setting, so you should not have to set it at all.

Perhaps you have useHttpOnly=false in your web application's
context.xml and it is overriding?

 Since i am using tomcat7 i dont think i need to configure 
 useHttpOnly=true explicitly.

You should not have to do so.

 Java code which generates the cookie
 
 response.setContentType(text/html); PrintWriter pw =
 response.getWriter(); Cookie cookie = new Cookie(url,testing
 userHttpOnly); Cookie cookie1 = new Cookie(Mr.x,testing the
 cookie); cookie.setMaxAge(60*60); //1 hour String sessionid =
 request.getSession().getId(); String contextPath =
 request.getContextPath(); response.setHeader(SET-COOKIE,
 JSESSIONID= + sessionid + ; Path= + contextPath); 
 response.addCookie(cookie); response.addCookie(cookie1); 
 pw.println(Cookies created);

Well, of course that code will not enable HttpOnly: you are creating
the cookie yourself by emitting the Set-Cookie header. If you had
let Tomcat create your JSESSIONID cookie for you, it would have
included the HttpOnly flag.

 With the below lines,i could see the ;HttpOnly along with the
 cookie information in the http header and the same java script code
 return undefined which is what i wanted. 
 response.setHeader(SET-COOKIE, JSESSIONID= + sessionid + ;
 Path= + contextPath + ; HttpOnly );
 
 Conclusion : As per my understanding the the cookie should be
 HttpOnly with the way i configured my context.xml.No java code is
 required for that.But this is not happening for me.Please let me
 know if i missed anything

Tomcat will not intercept your cookies and correct them to be
HttpOnly. That would be a violation of the servlet specification.
Tomcat will protect *its own* session cookie(s) by using the
HttpOnly flag, not just any cookie you happen to send back to the
client.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSjl4KAAoJEBzwKT+lPKRYoscQAJKTio8E9EeSSi6XkN3ZNv1o
ph0wpLYvWAKS9QiiXBmitK4ULFAxtJ1jH0cFqF84LxImwRN50jaS63AiFWZIwsiy
c28c9lTyCBcv5fNbRgW7qR2jPr+iilUjUbdt1KyDNoHmzecvrXizc+EXOxjeRQfG
Weww6V8YQH/QaQacddPq4rLsyibQl/YQ1dS5I+LAFPBEIilnKe8sqPUude9CrA86
l+vH6f6tbHWrMotE260ORFZCqs7LqhbjvWu0ZqT9pHuD5slK0a7HQvGH/GtCC8Dc
NENHF5lOshRMfoVrfaCgvx+1LPAblHePqUM/ZBBG9ZbXBrc5LihHKSktI/XVt3WB
NbThnKMqYnHJkotbe4znUfuDSokCEW/xEsnStpqUuhr1L6VjBHZ02ME0O2SfPglM
z8FNh7Gf92GZu2TOEesVXeIivO5T7c478x0yxWtL2F5230z1WHlUxnRhYlPbgjQz
WuIK8wp0IBsXSmd+leog1E2GAnJL3GkefxWWam4j9w+Xf4A1lfk1UYh1oCgD22zI
+IYMZMuKImYo0MZ9SkWCsVYBsakRsuoh/VH3/QMTB1QCIndDSGfcahcX0NT5R6vR
winJpj5h8IPMnM/nQEr/hsuPBUZ8EkhdsMd2YeclRBI5HidNqA6hhUN2QPBS9Yj0
5Bho1uInzvBd6QekswJj
=YBXm
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[toddfas]

Thanks very much for the quick response Niki!

I went down the configurator path too, but then I could not find a way
to pass the cookie values into the ServerEndPoint.onOpen where I need
to use it. I tried passing it via session.getRequestParameterMap() but
that is a Collections.unmodifiableMap(). In my scenario the
session.getHttpSession() is NULL so I can't put it in there. I didn't
like the idea of putting it in ThreadLocal (unless I am guaranteed by
the spec that ServerEndPoint.onOpen is always called on the same
thread that processes the handshake).

That was when I started thinking I must be missing something simple.
Any suggestions?

Thanks,
Todd


On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com wrote:
 On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:

 I'm trying to figure out how to get access to the cookies and headers
 passed up in the Websocket handshake request on Tomcat 8.

 In Tomcat 7 the whole HttpServletRequest was passed into the
 WebSocketServlet. createWebSocketInbound method so it was easy to grab
 from the request headers. In Tomcat 8 the querystring and URI are both
 exposed by the javax.websocket.Session passed to
 ServerEndPoint.onOpen, but I don't see a mechanism for getting the
 cookies or headers.


 You can supply an extension of
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
  and get
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
 through
 modifyHandshake invoked by the container during processing of client 'GET'
 handshake message. Handshake request containes methods for inspecting the
 http request parameters and headers.



 We are integrating Websocket connections into an existing web app and
 want to use the cookies set by our web app in the Websocket connection
 process.

 Thanks for any insight.
 Todd

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[Niki Dokovski]

On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:

 Thanks very much for the quick response Niki!

 I went down the configurator path too, but then I could not find a way
 to pass the cookie values into the ServerEndPoint.onOpen where I need
 to use it. I tried passing it via session.getRequestParameterMap() but
 that is a Collections.unmodifiableMap(). In my scenario the
 session.getHttpSession() is NULL so I can't put it in there. I didn't
 like the idea of putting it in ThreadLocal (unless I am guaranteed by
 the spec that ServerEndPoint.onOpen is always called on the same
 thread that processes the handshake).

 That was when I started thinking I must be missing something simple.
 Any suggestions?


Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
designates an established connection and that means you are already in the
websocket world. I don;t see an easy way for doing this. Can you describe
the use case in greater details. What problem do you solve by having access
to the handshale request headers  (incl cookies) in that phase?


 Thanks,
 Todd


 On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com wrote:
  On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
 
  I'm trying to figure out how to get access to the cookies and headers
  passed up in the Websocket handshake request on Tomcat 8.
 
  In Tomcat 7 the whole HttpServletRequest was passed into the
  WebSocketServlet. createWebSocketInbound method so it was easy to grab
  from the request headers. In Tomcat 8 the querystring and URI are both
  exposed by the javax.websocket.Session passed to
  ServerEndPoint.onOpen, but I don't see a mechanism for getting the
  cookies or headers.
 
 
  You can supply an extension of
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
   and get
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
  through
  modifyHandshake invoked by the container during processing of client
 'GET'
  handshake message. Handshake request containes methods for inspecting the
  http request parameters and headers.
 
 
 
  We are integrating Websocket connections into an existing web app and
  want to use the cookies set by our web app in the Websocket connection
  process.
 
  Thanks for any insight.
  Todd
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[toddfas]

Our existing web app has custom session management (does not use
JSESSIONID) and stores the session identifier in a cookie. The cookie is
marked httpOnly (and secure) so the client side Javascript opening the
websocket does not have access to it. I want to use this session identifier
in ServerEndPoint.onOpen to verify the user attempting to open the
Websocket connection and then be able to keep track of the user's context
as messages are received and sent over websocket.

Thanks for any additional ideas on how to accomplish this.
Todd


On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote:

 On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:

  Thanks very much for the quick response Niki!
 
  I went down the configurator path too, but then I could not find a way
  to pass the cookie values into the ServerEndPoint.onOpen where I need
  to use it. I tried passing it via session.getRequestParameterMap() but
  that is a Collections.unmodifiableMap(). In my scenario the
  session.getHttpSession() is NULL so I can't put it in there. I didn't
  like the idea of putting it in ThreadLocal (unless I am guaranteed by
  the spec that ServerEndPoint.onOpen is always called on the same
  thread that processes the handshake).
 
  That was when I started thinking I must be missing something simple.
  Any suggestions?
 

 Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
 designates an established connection and that means you are already in the
 websocket world. I don;t see an easy way for doing this. Can you describe
 the use case in greater details. What problem do you solve by having access
 to the handshale request headers  (incl cookies) in that phase?

 
  Thanks,
  Todd
 
 
  On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
 wrote:
   On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
  
   I'm trying to figure out how to get access to the cookies and headers
   passed up in the Websocket handshake request on Tomcat 8.
  
   In Tomcat 7 the whole HttpServletRequest was passed into the
   WebSocketServlet. createWebSocketInbound method so it was easy to grab
   from the request headers. In Tomcat 8 the querystring and URI are both
   exposed by the javax.websocket.Session passed to
   ServerEndPoint.onOpen, but I don't see a mechanism for getting the
   cookies or headers.
  
  
   You can supply an extension of
  
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
and get
  
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
   through
   modifyHandshake invoked by the container during processing of client
  'GET'
   handshake message. Handshake request containes methods for inspecting
 the
   http request parameters and headers.
  
  
  
   We are integrating Websocket connections into an existing web app and
   want to use the cookies set by our web app in the Websocket connection
   process.
  
   Thanks for any insight.
   Todd
  
   -
   To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: users-h...@tomcat.apache.org
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 

Re: Tomcat 8 Websocket API - Cookies Headers

[Nick Williams]

In the modifyHandshake method of your Configurator, you can call 
getUserProperties on the EndpointConfig argument. This returns a modifiable 
MapString, Object that you can add values to. After modifyHandshake returns 
and before onOpen is called, the values from that map are copied to the 
Session, and you can retrieve them by calling Session#getUserProperties(). 
That's how I'm passing Cookie and HttpSession objects into my endpoints' onOpen 
methods. For example:

public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest 
request, HandshakeResponse response) {

super.modifyHandshake(config, request, response);
config.getUserProperties.put(httpSessionObject, 
request.getHttpSession());
}
}

Then later:

@OnOpen
public void onOpen(Session session) {

HttpSession httpSession = (HttpSession) 
session.getUserProperties().get(httpSessionObject);
}

It ain't pretty. IMO, it was a serious design flaw in the spec not to provide 
ways to get the HttpSession and Cookies from the Session object. Maybe I'll try 
to get on the EG for the next version. :-)

N

On Aug 23, 2013, at 1:01 PM, toddfas wrote:

 Our existing web app has custom session management (does not use
 JSESSIONID) and stores the session identifier in a cookie. The cookie is
 marked httpOnly (and secure) so the client side Javascript opening the
 websocket does not have access to it. I want to use this session identifier
 in ServerEndPoint.onOpen to verify the user attempting to open the
 Websocket connection and then be able to keep track of the user's context
 as messages are received and sent over websocket.
 
 Thanks for any additional ideas on how to accomplish this.
 Todd
 
 
 On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote:
 
 On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
 
 Thanks very much for the quick response Niki!
 
 I went down the configurator path too, but then I could not find a way
 to pass the cookie values into the ServerEndPoint.onOpen where I need
 to use it. I tried passing it via session.getRequestParameterMap() but
 that is a Collections.unmodifiableMap(). In my scenario the
 session.getHttpSession() is NULL so I can't put it in there. I didn't
 like the idea of putting it in ThreadLocal (unless I am guaranteed by
 the spec that ServerEndPoint.onOpen is always called on the same
 thread that processes the handshake).
 
 That was when I started thinking I must be missing something simple.
 Any suggestions?
 
 
 Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
 designates an established connection and that means you are already in the
 websocket world. I don;t see an easy way for doing this. Can you describe
 the use case in greater details. What problem do you solve by having access
 to the handshale request headers  (incl cookies) in that phase?
 
 
 Thanks,
 Todd
 
 
 On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
 wrote:
 On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
 
 I'm trying to figure out how to get access to the cookies and headers
 passed up in the Websocket handshake request on Tomcat 8.
 
 In Tomcat 7 the whole HttpServletRequest was passed into the
 WebSocketServlet. createWebSocketInbound method so it was easy to grab
 from the request headers. In Tomcat 8 the querystring and URI are both
 exposed by the javax.websocket.Session passed to
 ServerEndPoint.onOpen, but I don't see a mechanism for getting the
 cookies or headers.
 
 
 You can supply an extension of
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
 and get
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
 through
 modifyHandshake invoked by the container during processing of client
 'GET'
 handshake message. Handshake request containes methods for inspecting
 the
 http request parameters and headers.
 
 
 
 We are integrating Websocket connections into an existing web app and
 want to use the cookies set by our web app in the Websocket connection
 process.
 
 Thanks for any insight.
 Todd
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[Nick Williams]

On Aug 23, 2013, at 1:25 PM, Nick Williams wrote:

 In the modifyHandshake method of your Configurator, you can call 
 getUserProperties on the EndpointConfig argument. This returns a modifiable 
 MapString, Object that you can add values to. After modifyHandshake returns 
 and before onOpen is called, the values from that map are copied to the 
 Session, and you can retrieve them by calling Session#getUserProperties(). 
 That's how I'm passing Cookie and HttpSession objects into my endpoints' 
 onOpen methods. For example:
 
 public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest 
 request, HandshakeResponse response) {
 
super.modifyHandshake(config, request, response);
config.getUserProperties.put(httpSessionObject, 
 request.getHttpSession());
}
 }
 
 Then later:
 
 @OnOpen
 public void onOpen(Session session) {
 
HttpSession httpSession = (HttpSession) 
 session.getUserProperties().get(httpSessionObject);
 }
 
 It ain't pretty. IMO, it was a serious design flaw in the spec not to provide 
 ways to get the HttpSession and Cookies from the Session object. Maybe I'll 
 try to get on the EG for the next version. :-)
 
 N
 
 On Aug 23, 2013, at 1:01 PM, toddfas wrote:
 
 Our existing web app has custom session management (does not use
 JSESSIONID) and stores the session identifier in a cookie. The cookie is
 marked httpOnly (and secure) so the client side Javascript opening the
 websocket does not have access to it. I want to use this session identifier
 in ServerEndPoint.onOpen to verify the user attempting to open the
 Websocket connection and then be able to keep track of the user's context
 as messages are received and sent over websocket.
 
 Thanks for any additional ideas on how to accomplish this.
 Todd
 
 
 On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote:
 
 On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
 
 Thanks very much for the quick response Niki!
 
 I went down the configurator path too, but then I could not find a way
 to pass the cookie values into the ServerEndPoint.onOpen where I need
 to use it. I tried passing it via session.getRequestParameterMap() but
 that is a Collections.unmodifiableMap(). In my scenario the
 session.getHttpSession() is NULL so I can't put it in there. I didn't
 like the idea of putting it in ThreadLocal (unless I am guaranteed by
 the spec that ServerEndPoint.onOpen is always called on the same
 thread that processes the handshake).
 
 That was when I started thinking I must be missing something simple.
 Any suggestions?
 
 
 Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
 designates an established connection and that means you are already in the
 websocket world. I don;t see an easy way for doing this. Can you describe
 the use case in greater details. What problem do you solve by having access
 to the handshale request headers  (incl cookies) in that phase?
 
 
 Thanks,
 Todd
 
 
 On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
 wrote:
 On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
 
 I'm trying to figure out how to get access to the cookies and headers
 passed up in the Websocket handshake request on Tomcat 8.
 
 In Tomcat 7 the whole HttpServletRequest was passed into the
 WebSocketServlet. createWebSocketInbound method so it was easy to grab
 from the request headers. In Tomcat 8 the querystring and URI are both
 exposed by the javax.websocket.Session passed to
 ServerEndPoint.onOpen, but I don't see a mechanism for getting the
 cookies or headers.
 
 
 You can supply an extension of
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
 and get
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
 through
 modifyHandshake invoked by the container during processing of client
 'GET'
 handshake message. Handshake request containes methods for inspecting
 the
 http request parameters and headers.
 
 
 
 We are integrating Websocket connections into an existing web app and
 want to use the cookies set by our web app in the Websocket connection
 process.
 
 Thanks for any insight.
 Todd

I'm sorry I top-posted! Didn't mean to. :-)

Nick


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[toddfas]

On Fri, Aug 23, 2013 at 11:25 AM, Nick Williams 
nicho...@nicholaswilliams.net wrote:

 In the modifyHandshake method of your Configurator, you can call
 getUserProperties on the EndpointConfig argument. This returns a modifiable
 MapString, Object that you can add values to. After modifyHandshake
 returns and before onOpen is called, the values from that map are copied to
 the Session, and you can retrieve them by calling
 Session#getUserProperties(). That's how I'm passing Cookie and HttpSession
 objects into my endpoints' onOpen methods. For example:

 public class MyConfigurator extends ServerEndpointConfig.Configurator {
 public void modifyHandshake(ServerEndpointConfig config,
 HandshakeRequest request, HandshakeResponse response) {

 super.modifyHandshake(config, request, response);
 config.getUserProperties.put(httpSessionObject,
 request.getHttpSession());
 }
 }

 Then later:

 @OnOpen
 public void onOpen(Session session) {

 HttpSession httpSession = (HttpSession)
 session.getUserProperties().get(httpSessionObject);
 }

 It ain't pretty. IMO, it was a serious design flaw in the spec not to
 provide ways to get the HttpSession and Cookies from the Session object.
 Maybe I'll try to get on the EG for the next version. :-)

 N

 On Aug 23, 2013, at 1:01 PM, toddfas wrote:

  Our existing web app has custom session management (does not use
  JSESSIONID) and stores the session identifier in a cookie. The cookie is
  marked httpOnly (and secure) so the client side Javascript opening the
  websocket does not have access to it. I want to use this session
 identifier
  in ServerEndPoint.onOpen to verify the user attempting to open the
  Websocket connection and then be able to keep track of the user's context
  as messages are received and sent over websocket.
 
  Thanks for any additional ideas on how to accomplish this.
  Todd
 
 
  On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com
 wrote:
 
  On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
 
  Thanks very much for the quick response Niki!
 
  I went down the configurator path too, but then I could not find a way
  to pass the cookie values into the ServerEndPoint.onOpen where I need
  to use it. I tried passing it via session.getRequestParameterMap() but
  that is a Collections.unmodifiableMap(). In my scenario the
  session.getHttpSession() is NULL so I can't put it in there. I didn't
  like the idea of putting it in ThreadLocal (unless I am guaranteed by
  the spec that ServerEndPoint.onOpen is always called on the same
  thread that processes the handshake).
 
  That was when I started thinking I must be missing something simple.
  Any suggestions?
 
 
  Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
  designates an established connection and that means you are already in
 the
  websocket world. I don;t see an easy way for doing this. Can you
 describe
  the use case in greater details. What problem do you solve by having
 access
  to the handshale request headers  (incl cookies) in that phase?
 
 
  Thanks,
  Todd
 
 
  On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
  wrote:
  On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
 
  I'm trying to figure out how to get access to the cookies and headers
  passed up in the Websocket handshake request on Tomcat 8.
 
  In Tomcat 7 the whole HttpServletRequest was passed into the
  WebSocketServlet. createWebSocketInbound method so it was easy to
 grab
  from the request headers. In Tomcat 8 the querystring and URI are
 both
  exposed by the javax.websocket.Session passed to
  ServerEndPoint.onOpen, but I don't see a mechanism for getting the
  cookies or headers.
 
 
  You can supply an extension of
 
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
  and get
 
 
 
 http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
  through
  modifyHandshake invoked by the container during processing of client
  'GET'
  handshake message. Handshake request containes methods for inspecting
  the
  http request parameters and headers.
 
 
 
  We are integrating Websocket connections into an existing web app and
  want to use the cookies set by our web app in the Websocket
 connection
  process.
 
  Thanks for any insight.
  Todd
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h

Tomcat 8 Websocket API - Cookies Headers

[toddfas]

I'm trying to figure out how to get access to the cookies and headers
passed up in the Websocket handshake request on Tomcat 8.

In Tomcat 7 the whole HttpServletRequest was passed into the
WebSocketServlet. createWebSocketInbound method so it was easy to grab
from the request headers. In Tomcat 8 the querystring and URI are both
exposed by the javax.websocket.Session passed to
ServerEndPoint.onOpen, but I don't see a mechanism for getting the
cookies or headers.

We are integrating Websocket connections into an existing web app and
want to use the cookies set by our web app in the Websocket connection
process.

Thanks for any insight.
Todd

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 Websocket API - Cookies Headers

[Niki Dokovski]

On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:

 I'm trying to figure out how to get access to the cookies and headers
 passed up in the Websocket handshake request on Tomcat 8.

 In Tomcat 7 the whole HttpServletRequest was passed into the
 WebSocketServlet. createWebSocketInbound method so it was easy to grab
 from the request headers. In Tomcat 8 the querystring and URI are both
 exposed by the javax.websocket.Session passed to
 ServerEndPoint.onOpen, but I don't see a mechanism for getting the
 cookies or headers.


You can supply an extension of
http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
 and get
http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
through
modifyHandshake invoked by the container during processing of client 'GET'
handshake message. Handshake request containes methods for inspecting the
http request parameters and headers.



 We are integrating Websocket connections into an existing web app and
 want to use the cookies set by our web app in the Websocket connection
 process.

 Thanks for any insight.
 Todd

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: secure cookies

[Prafull]

On Tue, Jul 30, 2013 at 9:39 PM, Jeffrey Janner jeffrey.jan...@polydyne.com
 wrote:

  -Original Message-
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Sent: Monday, July 29, 2013 8:21 PM
  To: Tomcat Users List
  Subject: Re: secure cookies
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Jeffrey,
 
  On 7/29/13 4:09 PM, Jeffrey Janner wrote:
   Thanks for the verification, Mark.  I was under the impression you'd
   only want to [set secure=true] if you were already front-ending the
   site with something that was doing the SSL for you (e.g. httpd or a
   proxy), and the server spoke HTTP between each other.
 
  We use secure=true for loopback-only connectors to avoid the overhead
  of SSL when we know the requests are going to come from localhost (we
  have Apache Cocoon running in a separate JVM calling-back to our main
  webapp for some XML). So there are some non-fronting use cases, too.
 
  (Note that mod_jk already sets the secure flag with each request if
  the original request to httpd came over HTTPS.)
 
   Our app accepts an initial request to the login page on HTTP, but
   should be automatically routed to the HTTPS connector due to
   transport-guarantee before the page is actually sent back.  Then we
   actually invalidate the session and create a new on successful login,
   and that session/cookie is used for the rest of the user's time on
  the
   site. So all I really need to do to implement at 6.x is the context
   change.
 
  Tomcat changes the session id (without actually destroying the
  session) after authentication, so if you are using Tomcat's
  authentication, then there is no need for the invalidation you describe
  above.
 
 We don't use Tomcat Auth, though I'm arguing for changing to Tomcat w/Form
 Auth so it's easier to support 2-factor auth for those customers who insist
 on it.  I'm not sure of the exact methodology employed, but I'm sure it's
 similar.



Thanks Christopher for the clarification and the link
-- 
BR,
Prafull

Re: secure cookies

[Prafull]

On Tue, Jul 30, 2013 at 6:51 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jeffrey,

 On 7/29/13 4:09 PM, Jeffrey Janner wrote:
  Thanks for the verification, Mark.  I was under the impression
  you'd only want to [set secure=true] if you were already
  front-ending the site with something that was doing the SSL for you
  (e.g. httpd or a proxy), and the server spoke HTTP between each
  other.

 We use secure=true for loopback-only connectors to avoid the
 overhead of SSL when we know the requests are going to come from
 localhost (we have Apache Cocoon running in a separate JVM
 calling-back to our main webapp for some XML). So there are some
 non-fronting use cases, too.

 (Note that mod_jk already sets the secure flag with each request if
 the original request to httpd came over HTTPS.)

  Our app accepts an initial request to the login page on HTTP, but
  should be automatically routed to the HTTPS connector due to
  transport-guarantee before the page is actually sent back.  Then
  we actually invalidate the session and create a new on successful
  login, and that session/cookie is used for the rest of the user's
  time on the site. So all I really need to do to implement at 6.x is
  the context change.

 Tomcat changes the session id (without actually destroying the
 session) after authentication, so if you are using Tomcat's
 authentication, then there is no need for the invalidation you
 describe above.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJR9xURAAoJEBzwKT+lPKRYVdIQAIrWoSOO3bSCTb0Ot6B7r9xy
 mGGlc3AwAImitS/FvWB2Rjx60doth8MqTD8A31abK+Ec9Gd1cbsWqTgea3VddYO7
 HYJfFrC4Nn7hcnsBXKkCjfJ/fnDzcodQrfg1aw/fbQpxVFzuEFI0JkIHdT1XE196
 zz6yy/hIo0X32HMRVK4rQYVdxDtDbgMyWbHB62PilxiLXvSzX3X2BN5F6qECy3+N
 BsVKeuG5SYITOySQ5lfCxSY47e9tzjmYcvfoEh+PqZoLl28SjRuv8j8zUqLVUBzf
 n+w3GFK7qdEt7QJdOA2uMmNS8NV5B18NjckVI5xyKtHmGrLlLBSSSVNHaQbZbYK/
 KzpBDdCv77UMS+RMgl7v1SfoNhRjiE+TYaDevwKrKs59+vXiv7TxyTcSuwDyB9zh
 zx9vxK/OGA667FesOUkTC4NFewl/5HWpulJvhhs2jj61E54EqzemQO789mZykhyZ
 COujCJXYqcpvas4gp+UGviacrjFTbQ7DWi0dzGhTzrlexLyK/5TjMsurUaK/lBYv
 GsDXxkQVGGZoP0ZKfoi+bYJKFTb3nUqHEGc17BXjlFT+nSB0Otb5QbpumtBpoOmQ
 dyltiro4acsP5fxSpJnHYXVr7i+UQg+c+RiHeJRPFKBLWKcwLYf/Dcu1AD9Crfw0
 eCjLf9tOerjoA+PeKGFr
 =ZKug
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

 Hi Christopher,

When you say after successful authentication tomcat re-creates a new
session, what do you mean by that? Can you explain it in bit more details?


-- 
BR,
Prafull

Re: secure cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Prafull,

On 7/30/13 9:44 AM, Prafull wrote:
 On Tue, Jul 30, 2013 at 6:51 AM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Jeffrey,
 
 On 7/29/13 4:09 PM, Jeffrey Janner wrote:
 Thanks for the verification, Mark.  I was under the
 impression you'd only want to [set secure=true] if you were
 already front-ending the site with something that was doing
 the SSL for you (e.g. httpd or a proxy), and the server spoke
 HTTP between each other.
 
 We use secure=true for loopback-only connectors to avoid the 
 overhead of SSL when we know the requests are going to come from 
 localhost (we have Apache Cocoon running in a separate JVM 
 calling-back to our main webapp for some XML). So there are some 
 non-fronting use cases, too.
 
 (Note that mod_jk already sets the secure flag with each request
 if the original request to httpd came over HTTPS.)
 
 Our app accepts an initial request to the login page on HTTP,
 but should be automatically routed to the HTTPS connector due
 to transport-guarantee before the page is actually sent
 back.  Then we actually invalidate the session and create a
 new on successful login, and that session/cookie is used for
 the rest of the user's time on the site. So all I really need
 to do to implement at 6.x is the context change.
 
 Tomcat changes the session id (without actually destroying the 
 session) after authentication, so if you are using Tomcat's 
 authentication, then there is no need for the invalidation you 
 describe above.
 
 -chris
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 Hi Christopher,
 
 When you say after successful authentication tomcat re-creates a
 new session, what do you mean by that? Can you explain it in bit
 more details?

I didn't say that Tomcat re-created a new session. In fact, I said
the opposite: Tomcat does not destroy the session. Instead, it changes
the session identifier associated with the existing session. This is
done to prevent session-fixation attacks.

You can read all about it here:
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR98zLAAoJEBzwKT+lPKRYgUYP/1NOvgOUEP7Oe74J36pTEzeH
ixUJrV2B9Iiju9XLrkhwRwEXALcVyUoDPeXMfGnsoJY5o26XnXLApXDwoNCIGnPu
NbbLNOs7syHJsd1ClptU3V8ySQ39X00BRF/qiT+32HmMoSb9gIoMyU7Wj/+Eytpi
QJ8a1G2IwyUlCfmfcZSXGbfOTNIO8bwJeeZtRamioCuSrZjVhguB7XK+IL2llhUP
sgp5tpc5LXiJaTF/C81i1dJjfffae2/lY/zNWTv7uxBQ+bgQWMG53yR0GRaWVtuo
EtM4N79eM/2b5kWCcOHBn7DNmhwITTvsOJGh0TRIMwdVT/AsiKXw4w+REHA9xB6r
0gpGR2Zdpf63IktWwfG/ZnFqmEgbABasV6O4/Vv0Idwxx1D00IyLm1KStvv8sOha
78eQ5RZM+iQ22L3KvBKn+o3spmQ66m7QPr/I9nkbipsTHxDK0MObM8ei6SAhBQec
RT7vHk+WoUomaLJUQFnyuIVkiOdPtefsGQM9m8Q5TtQ7hyPRLydUwnSd7yRnUenO
nMKfQT/zImhrcXjy8jKH9fVQWBlOmKJNcU/WZogJ7s23PS8/Ei1PLMNiXh60N/Ok
xZxQ9LP4O/60EYHE4zRToj95qILnBxqwIhWM9h8lpv/YeqrF9/yltfql0BDXs5XO
z+cdjl7S/BFf7ZUNKVmO
=B93k
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org