Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Did you managed to check the PR?

Lazar

On Tue, Mar 10, 2020 at 5:41 PM Lazar Kirchev 
wrote:

> Chris,
>
> Any update on this? Did you have a chance to have a look on the PR?
>
> Lazar
>
> On Wed, Mar 4, 2020 at 10:55 AM Lazar Kirchev 
> wrote:
>
>> Chris, Martin,
>>
>> Here is the PR: https://github.com/apache/tomcat/pull/252
>>
>> Lazar
>>
>> On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov 
>> wrote:
>>
>>> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev 
>>> wrote:
>>>
>>> > Chris,
>>> >
>>> > I just thought that I have some concerns passing a map with the
>>> headers to
>>> > generateCookie() method. This means that for each call the caller will
>>> have
>>> > to read all headers from the coyote.Response and put them in a map,
>>> even if
>>> > the CookieProcessor will not need them, as is the case with the legacy
>>> > cookie processor and the rfc cookie processor. This might have
>>> performance
>>> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request
>>> -
>>> > like generateCookie (Request, Cookie) - and then if the cookie
>>> processor
>>> > implementation needs headers, it will take them - only these which it
>>> needs
>>> > - from the Response.
>>> > What do you think?
>>> >
>>>
>>> I agree that this is a better way!
>>>
>>> Martin
>>>
>>>
>>> >
>>> > Lazar
>>> >
>>> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev 
>>> wrote:
>>> >
>>> > >
>>> > > Chris,
>>> > >
>>> > > Actually in my preferred option the implementation in the
>>> > > CookieProcessorBase should not be no-op, but it should call
>>> > > CookieProcessor.generateCookie(Cookie). And the calls to
>>> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response
>>> and
>>> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to
>>> the
>>> > new
>>> > > method.
>>> > >
>>> > > Lazar
>>> > >
>>> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev <
>>> lazar.kirc...@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Chris,
>>> > >>
>>> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5
>>> should
>>> > >> be able to work both on Java 7 and Java 8, interface default methods
>>> > can't
>>> > >> be used. So would you prefer to have a second
>>> > CookieProcessor.generateCookie(Map<>
>>> > >> requestHeaders, Cookie) in addition to the existing
>>> > CookieProcessor.generateCookie(Cookie),
>>> > >> and provide a no-op implementation in the CookieProcessorBase
>>> class, or
>>> > to
>>> > >> change the signature of the existing method instead? I myself
>>> prefer the
>>> > >> first option, with adding a second method.
>>> > >>
>>> > >> Lazar
>>> > >>
>>> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
>>> > >> ch...@christopherschultz.net> wrote:
>>> > >>
>>> > >>> -BEGIN PGP SIGNED MESSAGE-
>>> > >>> Hash: SHA256
>>> > >>>
>>> > >>> Lazar,
>>> > >>>
>>> > >>> On 2/24/20 02:05, Lazar Kirchev wrote:
>>> > >>> > Chris,
>>> > >>> >
>>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
>>> > >>> > work perfectly for me and I guess for anyone who needs to check
>>> the
>>> > >>> > client version.
>>> > >>>
>>> > >>> Want to prepare a PR?
>>> > >>>
>>> > >>> - -chris
>>> > >>>
>>> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
>>> > >>> > ch...@christopherschultz.net> wrote:
>>> > >>> >
>>> > >>> > Lazar,
>>> > >>> >
>>> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote:
>>> > >>>  Yes, the SameSite attribute is still in a draft and this
>>> > >>>  causes the mess, at least partly.> And yes, I was thinking
>>> > >>>  about something like that -
>>> > >>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
>>> > >>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
>>> > >>>  I
>>> > >>> > absolutely
>>> > >>>  agree that this would be very hacky. And it might be
>>> > >>>  dangerous as CookieProcessor is an interface and there
>>> > >>>  already might be custom implementations.
>>> > >>> >
>>> > >>> > We can fix that with default implementations, for Java versions
>>> > >>> > that support such thing (Java >= 1.8).
>>> > >>> >
>>> > >>>  But can you think of another way of making the cookie
>>> > >>>  generation logic aware of the user agent header value?
>>> > >>> >
>>> > >>> > Not really.
>>> > >>> >
>>> > >>> > I have a preference for:
>>> > >>> >
>>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>>> > >>> >
>>> > >>> > This is because User-Agent might not be the only header which is
>>> > >>> > useful, here. For example, Google Chrome (amusingly enough) will
>>> > >>> > be removing the User-Agent header[1] in favor of "client
>>> > >>> > hints"[2].
>>> > >>> >
>>> > >>> > So you might have to look at more than one header at a time,
>>> > >>> > including possibly User-Agent.
>>> > >>> >
>>> > >>> > -chris
>>> > >>> >
>>> > >>> > [1]
>>> > >>> >
>>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
>>> > >>> n-
>>> > >>> >
>>

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Any update on this? Did you have a chance to have a look on the PR?

Lazar

On Wed, Mar 4, 2020 at 10:55 AM Lazar Kirchev 
wrote:

> Chris, Martin,
>
> Here is the PR: https://github.com/apache/tomcat/pull/252
>
> Lazar
>
> On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov 
> wrote:
>
>> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev 
>> wrote:
>>
>> > Chris,
>> >
>> > I just thought that I have some concerns passing a map with the headers
>> to
>> > generateCookie() method. This means that for each call the caller will
>> have
>> > to read all headers from the coyote.Response and put them in a map,
>> even if
>> > the CookieProcessor will not need them, as is the case with the legacy
>> > cookie processor and the rfc cookie processor. This might have
>> performance
>> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request -
>> > like generateCookie (Request, Cookie) - and then if the cookie processor
>> > implementation needs headers, it will take them - only these which it
>> needs
>> > - from the Response.
>> > What do you think?
>> >
>>
>> I agree that this is a better way!
>>
>> Martin
>>
>>
>> >
>> > Lazar
>> >
>> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev 
>> wrote:
>> >
>> > >
>> > > Chris,
>> > >
>> > > Actually in my preferred option the implementation in the
>> > > CookieProcessorBase should not be no-op, but it should call
>> > > CookieProcessor.generateCookie(Cookie). And the calls to
>> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
>> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the
>> > new
>> > > method.
>> > >
>> > > Lazar
>> > >
>> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev <
>> lazar.kirc...@gmail.com>
>> > > wrote:
>> > >
>> > >> Chris,
>> > >>
>> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5
>> should
>> > >> be able to work both on Java 7 and Java 8, interface default methods
>> > can't
>> > >> be used. So would you prefer to have a second
>> > CookieProcessor.generateCookie(Map<>
>> > >> requestHeaders, Cookie) in addition to the existing
>> > CookieProcessor.generateCookie(Cookie),
>> > >> and provide a no-op implementation in the CookieProcessorBase class,
>> or
>> > to
>> > >> change the signature of the existing method instead? I myself prefer
>> the
>> > >> first option, with adding a second method.
>> > >>
>> > >> Lazar
>> > >>
>> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
>> > >> ch...@christopherschultz.net> wrote:
>> > >>
>> > >>> -BEGIN PGP SIGNED MESSAGE-
>> > >>> Hash: SHA256
>> > >>>
>> > >>> Lazar,
>> > >>>
>> > >>> On 2/24/20 02:05, Lazar Kirchev wrote:
>> > >>> > Chris,
>> > >>> >
>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
>> > >>> > work perfectly for me and I guess for anyone who needs to check
>> the
>> > >>> > client version.
>> > >>>
>> > >>> Want to prepare a PR?
>> > >>>
>> > >>> - -chris
>> > >>>
>> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
>> > >>> > ch...@christopherschultz.net> wrote:
>> > >>> >
>> > >>> > Lazar,
>> > >>> >
>> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote:
>> > >>>  Yes, the SameSite attribute is still in a draft and this
>> > >>>  causes the mess, at least partly.> And yes, I was thinking
>> > >>>  about something like that -
>> > >>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
>> > >>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
>> > >>>  I
>> > >>> > absolutely
>> > >>>  agree that this would be very hacky. And it might be
>> > >>>  dangerous as CookieProcessor is an interface and there
>> > >>>  already might be custom implementations.
>> > >>> >
>> > >>> > We can fix that with default implementations, for Java versions
>> > >>> > that support such thing (Java >= 1.8).
>> > >>> >
>> > >>>  But can you think of another way of making the cookie
>> > >>>  generation logic aware of the user agent header value?
>> > >>> >
>> > >>> > Not really.
>> > >>> >
>> > >>> > I have a preference for:
>> > >>> >
>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>> > >>> >
>> > >>> > This is because User-Agent might not be the only header which is
>> > >>> > useful, here. For example, Google Chrome (amusingly enough) will
>> > >>> > be removing the User-Agent header[1] in favor of "client
>> > >>> > hints"[2].
>> > >>> >
>> > >>> > So you might have to look at more than one header at a time,
>> > >>> > including possibly User-Agent.
>> > >>> >
>> > >>> > -chris
>> > >>> >
>> > >>> > [1]
>> > >>> >
>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
>> > >>> n-
>> > >>> >
>> > >>> >
>> > >>> chrome/
>> > >>> > <
>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-
>> > >>> in-chrome/
>> > >>> <
>> >
>> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/
>> > >
>> > >>> >
>> > >>> >
>> > >>> >  [2

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris, Martin,

Here is the PR: https://github.com/apache/tomcat/pull/252

Lazar

On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov 
wrote:

> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev 
> wrote:
>
> > Chris,
> >
> > I just thought that I have some concerns passing a map with the headers
> to
> > generateCookie() method. This means that for each call the caller will
> have
> > to read all headers from the coyote.Response and put them in a map, even
> if
> > the CookieProcessor will not need them, as is the case with the legacy
> > cookie processor and the rfc cookie processor. This might have
> performance
> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request -
> > like generateCookie (Request, Cookie) - and then if the cookie processor
> > implementation needs headers, it will take them - only these which it
> needs
> > - from the Response.
> > What do you think?
> >
>
> I agree that this is a better way!
>
> Martin
>
>
> >
> > Lazar
> >
> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev 
> wrote:
> >
> > >
> > > Chris,
> > >
> > > Actually in my preferred option the implementation in the
> > > CookieProcessorBase should not be no-op, but it should call
> > > CookieProcessor.generateCookie(Cookie). And the calls to
> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the
> > new
> > > method.
> > >
> > > Lazar
> > >
> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev  >
> > > wrote:
> > >
> > >> Chris,
> > >>
> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5
> should
> > >> be able to work both on Java 7 and Java 8, interface default methods
> > can't
> > >> be used. So would you prefer to have a second
> > CookieProcessor.generateCookie(Map<>
> > >> requestHeaders, Cookie) in addition to the existing
> > CookieProcessor.generateCookie(Cookie),
> > >> and provide a no-op implementation in the CookieProcessorBase class,
> or
> > to
> > >> change the signature of the existing method instead? I myself prefer
> the
> > >> first option, with adding a second method.
> > >>
> > >> Lazar
> > >>
> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > >>> -BEGIN PGP SIGNED MESSAGE-
> > >>> Hash: SHA256
> > >>>
> > >>> Lazar,
> > >>>
> > >>> On 2/24/20 02:05, Lazar Kirchev wrote:
> > >>> > Chris,
> > >>> >
> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> > >>> > work perfectly for me and I guess for anyone who needs to check the
> > >>> > client version.
> > >>>
> > >>> Want to prepare a PR?
> > >>>
> > >>> - -chris
> > >>>
> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> > >>> > ch...@christopherschultz.net> wrote:
> > >>> >
> > >>> > Lazar,
> > >>> >
> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote:
> > >>>  Yes, the SameSite attribute is still in a draft and this
> > >>>  causes the mess, at least partly.> And yes, I was thinking
> > >>>  about something like that -
> > >>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
> > >>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
> > >>>  I
> > >>> > absolutely
> > >>>  agree that this would be very hacky. And it might be
> > >>>  dangerous as CookieProcessor is an interface and there
> > >>>  already might be custom implementations.
> > >>> >
> > >>> > We can fix that with default implementations, for Java versions
> > >>> > that support such thing (Java >= 1.8).
> > >>> >
> > >>>  But can you think of another way of making the cookie
> > >>>  generation logic aware of the user agent header value?
> > >>> >
> > >>> > Not really.
> > >>> >
> > >>> > I have a preference for:
> > >>> >
> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
> > >>> >
> > >>> > This is because User-Agent might not be the only header which is
> > >>> > useful, here. For example, Google Chrome (amusingly enough) will
> > >>> > be removing the User-Agent header[1] in favor of "client
> > >>> > hints"[2].
> > >>> >
> > >>> > So you might have to look at more than one header at a time,
> > >>> > including possibly User-Agent.
> > >>> >
> > >>> > -chris
> > >>> >
> > >>> > [1]
> > >>> >
> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
> > >>> n-
> > >>> >
> > >>> >
> > >>> chrome/
> > >>> > <
> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-
> > >>> in-chrome/
> > >>> <
> >
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/
> > >
> > >>> >
> > >>> >
> > >>> >  [2] https://wicg.github.io/ua-client-hints/
> > >>> >
> > >>>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
> > >>>  ch...@christopherschultz.net> wrote:
> > >>> 
> > >>>  Lazar,
> > >>> 
> > >>>  On 2/14/20 05:36, Lazar Kirchev wrote:
> > >>> >>> Chris,
> > >>> >>>
> > >>> >>> Just

Re: cookie configurations for Tomcat 7

[Martin Grigorov]

On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev 
wrote:

> Chris,
>
> I just thought that I have some concerns passing a map with the headers to
> generateCookie() method. This means that for each call the caller will have
> to read all headers from the coyote.Response and put them in a map, even if
> the CookieProcessor will not need them, as is the case with the legacy
> cookie processor and the rfc cookie processor. This might have performance
> impact. Isn't it more optimal to just pass the o.a.c.connector.Request -
> like generateCookie (Request, Cookie) - and then if the cookie processor
> implementation needs headers, it will take them - only these which it needs
> - from the Response.
> What do you think?
>

I agree that this is a better way!

Martin


>
> Lazar
>
> On Fri, Feb 28, 2020, 17:08 Lazar Kirchev  wrote:
>
> >
> > Chris,
> >
> > Actually in my preferred option the implementation in the
> > CookieProcessorBase should not be no-op, but it should call
> > CookieProcessor.generateCookie(Cookie). And the calls to
> > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
> > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the
> new
> > method.
> >
> > Lazar
> >
> > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev 
> > wrote:
> >
> >> Chris,
> >>
> >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should
> >> be able to work both on Java 7 and Java 8, interface default methods
> can't
> >> be used. So would you prefer to have a second
> CookieProcessor.generateCookie(Map<>
> >> requestHeaders, Cookie) in addition to the existing
> CookieProcessor.generateCookie(Cookie),
> >> and provide a no-op implementation in the CookieProcessorBase class, or
> to
> >> change the signature of the existing method instead? I myself prefer the
> >> first option, with adding a second method.
> >>
> >> Lazar
> >>
> >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> Lazar,
> >>>
> >>> On 2/24/20 02:05, Lazar Kirchev wrote:
> >>> > Chris,
> >>> >
> >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> >>> > work perfectly for me and I guess for anyone who needs to check the
> >>> > client version.
> >>>
> >>> Want to prepare a PR?
> >>>
> >>> - -chris
> >>>
> >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> >>> > ch...@christopherschultz.net> wrote:
> >>> >
> >>> > Lazar,
> >>> >
> >>> > On 2/21/20 10:29, Lazar Kirchev wrote:
> >>>  Yes, the SameSite attribute is still in a draft and this
> >>>  causes the mess, at least partly.> And yes, I was thinking
> >>>  about something like that -
> >>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
> >>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
> >>>  I
> >>> > absolutely
> >>>  agree that this would be very hacky. And it might be
> >>>  dangerous as CookieProcessor is an interface and there
> >>>  already might be custom implementations.
> >>> >
> >>> > We can fix that with default implementations, for Java versions
> >>> > that support such thing (Java >= 1.8).
> >>> >
> >>>  But can you think of another way of making the cookie
> >>>  generation logic aware of the user agent header value?
> >>> >
> >>> > Not really.
> >>> >
> >>> > I have a preference for:
> >>> >
> >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
> >>> >
> >>> > This is because User-Agent might not be the only header which is
> >>> > useful, here. For example, Google Chrome (amusingly enough) will
> >>> > be removing the User-Agent header[1] in favor of "client
> >>> > hints"[2].
> >>> >
> >>> > So you might have to look at more than one header at a time,
> >>> > including possibly User-Agent.
> >>> >
> >>> > -chris
> >>> >
> >>> > [1]
> >>> >
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
> >>> n-
> >>> >
> >>> >
> >>> chrome/
> >>> > <
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-
> >>> in-chrome/
> >>> <
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/
> >
> >>> >
> >>> >
> >>> >  [2] https://wicg.github.io/ua-client-hints/
> >>> >
> >>>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
> >>>  ch...@christopherschultz.net> wrote:
> >>> 
> >>>  Lazar,
> >>> 
> >>>  On 2/14/20 05:36, Lazar Kirchev wrote:
> >>> >>> Chris,
> >>> >>>
> >>> >>> Just FYI or in case someone else hits this problem.
> >>> >>>
> >>> >>> Actually I had to use the response wrapper approach
> >>> >>> for Tomcat 8.5.50 as well. As described by Chrome in
> >>> >>>
> https://www.chromium.org/updates/same-site/incompatible-clients,
> >>> >>>
> >>> >>>
> >>> >
> >>> >>>
> >>> there are older browser versions which do not support the SameSite
> >>> >>> attribute at all and reject t

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

I just thought that I have some concerns passing a map with the headers to
generateCookie() method. This means that for each call the caller will have
to read all headers from the coyote.Response and put them in a map, even if
the CookieProcessor will not need them, as is the case with the legacy
cookie processor and the rfc cookie processor. This might have performance
impact. Isn't it more optimal to just pass the o.a.c.connector.Request -
like generateCookie (Request, Cookie) - and then if the cookie processor
implementation needs headers, it will take them - only these which it needs
- from the Response.
What do you think?

Lazar

On Fri, Feb 28, 2020, 17:08 Lazar Kirchev  wrote:

>
> Chris,
>
> Actually in my preferred option the implementation in the
> CookieProcessorBase should not be no-op, but it should call
> CookieProcessor.generateCookie(Cookie). And the calls to
> CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
> o.a.c.core.ApplicationPushBuilder should be replaced with calls to the new
> method.
>
> Lazar
>
> On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev 
> wrote:
>
>> Chris,
>>
>> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should
>> be able to work both on Java 7 and Java 8, interface default methods can't
>> be used. So would you prefer to have a second 
>> CookieProcessor.generateCookie(Map<>
>> requestHeaders, Cookie) in addition to the existing  
>> CookieProcessor.generateCookie(Cookie),
>> and provide a no-op implementation in the CookieProcessorBase class, or to
>> change the signature of the existing method instead? I myself prefer the
>> first option, with adding a second method.
>>
>> Lazar
>>
>> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Lazar,
>>>
>>> On 2/24/20 02:05, Lazar Kirchev wrote:
>>> > Chris,
>>> >
>>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
>>> > work perfectly for me and I guess for anyone who needs to check the
>>> > client version.
>>>
>>> Want to prepare a PR?
>>>
>>> - -chris
>>>
>>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
>>> > ch...@christopherschultz.net> wrote:
>>> >
>>> > Lazar,
>>> >
>>> > On 2/21/20 10:29, Lazar Kirchev wrote:
>>>  Yes, the SameSite attribute is still in a draft and this
>>>  causes the mess, at least partly.> And yes, I was thinking
>>>  about something like that -
>>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
>>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
>>>  I
>>> > absolutely
>>>  agree that this would be very hacky. And it might be
>>>  dangerous as CookieProcessor is an interface and there
>>>  already might be custom implementations.
>>> >
>>> > We can fix that with default implementations, for Java versions
>>> > that support such thing (Java >= 1.8).
>>> >
>>>  But can you think of another way of making the cookie
>>>  generation logic aware of the user agent header value?
>>> >
>>> > Not really.
>>> >
>>> > I have a preference for:
>>> >
>>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>>> >
>>> > This is because User-Agent might not be the only header which is
>>> > useful, here. For example, Google Chrome (amusingly enough) will
>>> > be removing the User-Agent header[1] in favor of "client
>>> > hints"[2].
>>> >
>>> > So you might have to look at more than one header at a time,
>>> > including possibly User-Agent.
>>> >
>>> > -chris
>>> >
>>> > [1]
>>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
>>> n-
>>> >
>>> >
>>> chrome/
>>> > >> in-chrome/
>>> 
>>> >
>>> >
>>> >  [2] https://wicg.github.io/ua-client-hints/
>>> >
>>>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
>>>  ch...@christopherschultz.net> wrote:
>>> 
>>>  Lazar,
>>> 
>>>  On 2/14/20 05:36, Lazar Kirchev wrote:
>>> >>> Chris,
>>> >>>
>>> >>> Just FYI or in case someone else hits this problem.
>>> >>>
>>> >>> Actually I had to use the response wrapper approach
>>> >>> for Tomcat 8.5.50 as well. As described by Chrome in
>>> >>> https://www.chromium.org/updates/same-site/incompatible-clients,
>>> >>>
>>> >>>
>>> >
>>> >>>
>>> there are older browser versions which do not support the SameSite
>>> >>> attribute at all and reject the cookies which contain
>>> >>> it. Although Tomcat 8.5.42 and later provide the
>>> >>> CookieProcessor configuration for the SameSite
>>> >>> attribute, it is a problem if one wants to support
>>> >>> older browser versions as well.
>>>  Wow, what a huge pain in the neck. I don't see anything in
>>>  RFC 6265 that says anything about rejecting cookies 

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Actually in my preferred option the implementation in the
CookieProcessorBase should not be no-op, but it should call
CookieProcessor.generateCookie(Cookie). And the calls to
CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
o.a.c.core.ApplicationPushBuilder should be replaced with calls to the new
method.

Lazar

On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev 
wrote:

> Chris,
>
> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should
> be able to work both on Java 7 and Java 8, interface default methods can't
> be used. So would you prefer to have a second 
> CookieProcessor.generateCookie(Map<>
> requestHeaders, Cookie) in addition to the existing  
> CookieProcessor.generateCookie(Cookie),
> and provide a no-op implementation in the CookieProcessorBase class, or to
> change the signature of the existing method instead? I myself prefer the
> first option, with adding a second method.
>
> Lazar
>
> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Lazar,
>>
>> On 2/24/20 02:05, Lazar Kirchev wrote:
>> > Chris,
>> >
>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
>> > work perfectly for me and I guess for anyone who needs to check the
>> > client version.
>>
>> Want to prepare a PR?
>>
>> - -chris
>>
>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
>> > ch...@christopherschultz.net> wrote:
>> >
>> > Lazar,
>> >
>> > On 2/21/20 10:29, Lazar Kirchev wrote:
>>  Yes, the SameSite attribute is still in a draft and this
>>  causes the mess, at least partly.> And yes, I was thinking
>>  about something like that -
>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
>>  I
>> > absolutely
>>  agree that this would be very hacky. And it might be
>>  dangerous as CookieProcessor is an interface and there
>>  already might be custom implementations.
>> >
>> > We can fix that with default implementations, for Java versions
>> > that support such thing (Java >= 1.8).
>> >
>>  But can you think of another way of making the cookie
>>  generation logic aware of the user agent header value?
>> >
>> > Not really.
>> >
>> > I have a preference for:
>> >
>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>> >
>> > This is because User-Agent might not be the only header which is
>> > useful, here. For example, Google Chrome (amusingly enough) will
>> > be removing the User-Agent header[1] in favor of "client
>> > hints"[2].
>> >
>> > So you might have to look at more than one header at a time,
>> > including possibly User-Agent.
>> >
>> > -chris
>> >
>> > [1]
>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
>> n-
>> >
>> >
>> chrome/
>> > > in-chrome/
>> 
>> >
>> >
>> >  [2] https://wicg.github.io/ua-client-hints/
>> >
>>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
>>  ch...@christopherschultz.net> wrote:
>> 
>>  Lazar,
>> 
>>  On 2/14/20 05:36, Lazar Kirchev wrote:
>> >>> Chris,
>> >>>
>> >>> Just FYI or in case someone else hits this problem.
>> >>>
>> >>> Actually I had to use the response wrapper approach
>> >>> for Tomcat 8.5.50 as well. As described by Chrome in
>> >>> https://www.chromium.org/updates/same-site/incompatible-clients,
>> >>>
>> >>>
>> >
>> >>>
>> there are older browser versions which do not support the SameSite
>> >>> attribute at all and reject the cookies which contain
>> >>> it. Although Tomcat 8.5.42 and later provide the
>> >>> CookieProcessor configuration for the SameSite
>> >>> attribute, it is a problem if one wants to support
>> >>> older browser versions as well.
>>  Wow, what a huge pain in the neck. I don't see anything in
>>  RFC 6265 that says anything about rejecting cookies with
>>  unknown attributes, but I also don't see anything prohibiting
>>  that behavior, either. Than again, RFC 6265 doesn't mention
>>  the SameSite attribute at all, so ... there is that.
>> 
>>  This is what you get when vendors try to implement standards
>>  before they are standards.
>> 
>> >>> Adding the SameSite attribute in order to support
>> >>> newest Chrome breaks the old ones as the configuration
>> >>> via the CookieProcessor does not allow for user agent
>> >>> sniffing. Even if you extend the existing
>> >>> CookieProcessor implementations or create your own, you
>> >>> cannot get the request headers in it so that you can
>> >>> check for the browser version. If one needs such
>> >>> flexibility, only the response wrapper helps. Do you
>> >>> thi

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should be
able to work both on Java 7 and Java 8, interface default methods can't be
used. So would you prefer to have a second CookieProcessor.generateCookie(Map<>
requestHeaders, Cookie) in addition to the existing
CookieProcessor.generateCookie(Cookie),
and provide a no-op implementation in the CookieProcessorBase class, or to
change the signature of the existing method instead? I myself prefer the
first option, with adding a second method.

Lazar

On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 2/24/20 02:05, Lazar Kirchev wrote:
> > Chris,
> >
> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> > work perfectly for me and I guess for anyone who needs to check the
> > client version.
>
> Want to prepare a PR?
>
> - -chris
>
> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Lazar,
> >
> > On 2/21/20 10:29, Lazar Kirchev wrote:
>  Yes, the SameSite attribute is still in a draft and this
>  causes the mess, at least partly.> And yes, I was thinking
>  about something like that -
>  CookieProcessor.generateCookie(String userAgent, Cookie) or
>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
>  I
> > absolutely
>  agree that this would be very hacky. And it might be
>  dangerous as CookieProcessor is an interface and there
>  already might be custom implementations.
> >
> > We can fix that with default implementations, for Java versions
> > that support such thing (Java >= 1.8).
> >
>  But can you think of another way of making the cookie
>  generation logic aware of the user agent header value?
> >
> > Not really.
> >
> > I have a preference for:
> >
> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
> >
> > This is because User-Agent might not be the only header which is
> > useful, here. For example, Google Chrome (amusingly enough) will
> > be removing the User-Agent header[1] in favor of "client
> > hints"[2].
> >
> > So you might have to look at more than one header at a time,
> > including possibly User-Agent.
> >
> > -chris
> >
> > [1]
> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
> n-
> >
> >
> chrome/
> >  in-chrome/
> 
> >
> >
> >  [2] https://wicg.github.io/ua-client-hints/
> >
>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  Lazar,
> 
>  On 2/14/20 05:36, Lazar Kirchev wrote:
> >>> Chris,
> >>>
> >>> Just FYI or in case someone else hits this problem.
> >>>
> >>> Actually I had to use the response wrapper approach
> >>> for Tomcat 8.5.50 as well. As described by Chrome in
> >>> https://www.chromium.org/updates/same-site/incompatible-clients,
> >>>
> >>>
> >
> >>>
> there are older browser versions which do not support the SameSite
> >>> attribute at all and reject the cookies which contain
> >>> it. Although Tomcat 8.5.42 and later provide the
> >>> CookieProcessor configuration for the SameSite
> >>> attribute, it is a problem if one wants to support
> >>> older browser versions as well.
>  Wow, what a huge pain in the neck. I don't see anything in
>  RFC 6265 that says anything about rejecting cookies with
>  unknown attributes, but I also don't see anything prohibiting
>  that behavior, either. Than again, RFC 6265 doesn't mention
>  the SameSite attribute at all, so ... there is that.
> 
>  This is what you get when vendors try to implement standards
>  before they are standards.
> 
> >>> Adding the SameSite attribute in order to support
> >>> newest Chrome breaks the old ones as the configuration
> >>> via the CookieProcessor does not allow for user agent
> >>> sniffing. Even if you extend the existing
> >>> CookieProcessor implementations or create your own, you
> >>> cannot get the request headers in it so that you can
> >>> check for the browser version. If one needs such
> >>> flexibility, only the response wrapper helps. Do you
> >>> think that it makes sense to provide a mechanism in
> >>> the CookieProcessor to get access to the request
> >>> headers in order to check the user agent?
>  Are you referring to CookieProcessor.generateCookie(Cookie)?
>  So the proposal would be to change that to
>  CookieProcessor.generateCookie(String userAgent, Cookie)? Or
>  maybe even CookieProcessor.generateCookie(Map<>
>  rquestHeaders, Cookie)?
> 
>  It seems super hacky to do it that way, but I'm not sure I
>  see another option for introdu

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 2/24/20 02:05, Lazar Kirchev wrote:
> Chris,
>
> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> work perfectly for me and I guess for anyone who needs to check the
> client version.

Want to prepare a PR?

- -chris

> On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Lazar,
>
> On 2/21/20 10:29, Lazar Kirchev wrote:
 Yes, the SameSite attribute is still in a draft and this
 causes the mess, at least partly.> And yes, I was thinking
 about something like that -
 CookieProcessor.generateCookie(String userAgent, Cookie) or
 CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
 I
> absolutely
 agree that this would be very hacky. And it might be
 dangerous as CookieProcessor is an interface and there
 already might be custom implementations.
>
> We can fix that with default implementations, for Java versions
> that support such thing (Java >= 1.8).
>
 But can you think of another way of making the cookie
 generation logic aware of the user agent header value?
>
> Not really.
>
> I have a preference for:
>
> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>
> This is because User-Agent might not be the only header which is
> useful, here. For example, Google Chrome (amusingly enough) will
> be removing the User-Agent header[1] in favor of "client
> hints"[2].
>
> So you might have to look at more than one header at a time,
> including possibly User-Agent.
>
> -chris
>
> [1]
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
n-
>
>
chrome/
> 
>
>  [2] https://wicg.github.io/ua-client-hints/
>
 On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
 ch...@christopherschultz.net> wrote:

 Lazar,

 On 2/14/20 05:36, Lazar Kirchev wrote:
>>> Chris,
>>>
>>> Just FYI or in case someone else hits this problem.
>>>
>>> Actually I had to use the response wrapper approach
>>> for Tomcat 8.5.50 as well. As described by Chrome in
>>> https://www.chromium.org/updates/same-site/incompatible-clients,
>>>
>>>
>
>>>
there are older browser versions which do not support the SameSite
>>> attribute at all and reject the cookies which contain
>>> it. Although Tomcat 8.5.42 and later provide the
>>> CookieProcessor configuration for the SameSite
>>> attribute, it is a problem if one wants to support
>>> older browser versions as well.
 Wow, what a huge pain in the neck. I don't see anything in
 RFC 6265 that says anything about rejecting cookies with
 unknown attributes, but I also don't see anything prohibiting
 that behavior, either. Than again, RFC 6265 doesn't mention
 the SameSite attribute at all, so ... there is that.

 This is what you get when vendors try to implement standards
 before they are standards.

>>> Adding the SameSite attribute in order to support
>>> newest Chrome breaks the old ones as the configuration
>>> via the CookieProcessor does not allow for user agent
>>> sniffing. Even if you extend the existing
>>> CookieProcessor implementations or create your own, you
>>> cannot get the request headers in it so that you can
>>> check for the browser version. If one needs such
>>> flexibility, only the response wrapper helps. Do you
>>> think that it makes sense to provide a mechanism in
>>> the CookieProcessor to get access to the request
>>> headers in order to check the user agent?
 Are you referring to CookieProcessor.generateCookie(Cookie)?
 So the proposal would be to change that to
 CookieProcessor.generateCookie(String userAgent, Cookie)? Or
 maybe even CookieProcessor.generateCookie(Map<>
 rquestHeaders, Cookie)?

 It seems super hacky to do it that way, but I'm not sure I
 see another option for introducing SameSite in a compatible
 way.

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

>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5T6WwACgkQHPApP6U8
pFhGHxAAwiVqrNm6k4LjfFedovPEVPADUqGe1cT9UIB1seFUhPJ2u1REgVhOoAsq
EuIxnn69nRpqqtp31petFk7D1XMw9HQHgr6dXBJILL+fPxqZxvavDeM+jqXL/D4O
+UTzz85EXMl0A/HVkIYR9tb0kW3lgLEvdyYeWQB+0sz3pzdyIxW6ZtKOfRFOwjff
8ptTKz6XJN3gWyZ5dOwsJ+umPQeqOLoxn9bmlKJnXFZHsfzVhBUy2

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will work
perfectly for me and I guess for anyone who needs to check the client
version.

Kind regards,
Lazar

On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 2/21/20 10:29, Lazar Kirchev wrote:
> > Yes, the SameSite attribute is still in a draft and this causes
> > the mess, at least partly.> And yes, I was thinking about something
> > like that - CookieProcessor.generateCookie(String userAgent,
> > Cookie) or CookieProcessor.generateCookie(Map<> requestHeaders,
> > Cookie). I
> absolutely
> > agree that this would be very hacky. And it might be dangerous as
> > CookieProcessor is an interface and there already might be custom
> > implementations.
>
> We can fix that with default implementations, for Java versions that
> support such thing (Java >= 1.8).
>
> > But can you think of another way of making the cookie generation
> > logic aware of the user agent header value?
>
> Not really.
>
> I have a preference for:
>
> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>
> This is because User-Agent might not be the only header which is
> useful, here. For example, Google Chrome (amusingly enough) will be
> removing the User-Agent header[1] in favor of "client hints"[2].
>
> So you might have to look at more than one header at a time, including
> possibly User-Agent.
>
> - -chris
>
> [1]
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-
> chrome/
> 
>
> [2] https://wicg.github.io/ua-client-hints/
>
> > On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Lazar,
> >
> > On 2/14/20 05:36, Lazar Kirchev wrote:
>  Chris,
> 
>  Just FYI or in case someone else hits this problem.
> 
>  Actually I had to use the response wrapper approach for
>  Tomcat 8.5.50 as well. As described by Chrome in
>  https://www.chromium.org/updates/same-site/incompatible-clients,
> 
> 
> there are older browser versions which do not support the SameSite
>  attribute at all and reject the cookies which contain it.
>  Although Tomcat 8.5.42 and later provide the CookieProcessor
>  configuration for the SameSite attribute, it is a problem if
>  one wants to support older browser versions as well.
> > Wow, what a huge pain in the neck. I don't see anything in RFC
> > 6265 that says anything about rejecting cookies with unknown
> > attributes, but I also don't see anything prohibiting that
> > behavior, either. Than again, RFC 6265 doesn't mention the SameSite
> > attribute at all, so ... there is that.
> >
> > This is what you get when vendors try to implement standards
> > before they are standards.
> >
>  Adding the SameSite attribute in order to support newest
>  Chrome breaks the old ones as the configuration via the
>  CookieProcessor does not allow for user agent sniffing. Even
>  if you extend the existing CookieProcessor implementations or
>  create your own, you cannot get the request headers in it so
>  that you can check for the browser version. If one needs such
>  flexibility, only the response wrapper helps. Do you think
>  that it makes sense to provide a mechanism in the
>  CookieProcessor to get access to the request headers in order
>  to check the user agent?
> > Are you referring to CookieProcessor.generateCookie(Cookie)? So
> > the proposal would be to change that to
> > CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe
> > even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)?
> >
> > It seems super hacky to do it that way, but I'm not sure I see
> > another option for introducing SameSite in a compatible way.
> >
> > -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/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5QEJgACgkQHPApP6U8
> pFgC6w/7BzMCRdeR4Kldjigj6R48AUWcUorN0R1tQu4pxOT04DWPPkC+qXWoCtkT
> MNB3VgAuqjPnNLUDaGskvhU73p4lGqa2Z2scFKfS7CjTDs/cgwTusl+/bHqynK1P
> zxea0tU5DQvVUNbo5tvfWhwzoE/7/5lCcevkmBIwinktNr7+tOygIFvJl0vR7g5J
> diXmOlG0ratoGcbxr6qCzb/X3q7aUwn2U/m3yakX6HXcWg4tbOeVX969w5NU4i7c
> G+u5I+ayMqZt4DOU/5izuknsBUtvTEn36INoYaUmlK72KZofh9MOU56dSE/lyyPd
> snL493LHkgnCjpA8Se4GDHEV/TUqvn1/c0sSRzf6dMgwnE2w61VtJVzDstklWhWW
> 0S9GoTb+yi89QLcCPSJA2ZWiS2kbPMnEPqxgHTFwkhnqKpyjr9hw4h5O4Qr6fLYs
> bD8QihLWvyjoa4ImpIQZ3n+6556OEGYg6fUO/RKlx3cLB7nplsXUr0IxpE3XFW9T
> iV4ZaiZHtT+CtrDVqy2DO1kzj5GAxaoUWTXsDN4sqCwvJnAUId1rBpz0B1yZPPQh
> vPB3z6E1RmfOynY1ZWI+i3oJDd02ytsKsfnMaOYcYe8

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 2/21/20 10:29, Lazar Kirchev wrote:
> Yes, the SameSite attribute is still in a draft and this causes
> the mess, at least partly.> And yes, I was thinking about something
> like that - CookieProcessor.generateCookie(String userAgent,
> Cookie) or CookieProcessor.generateCookie(Map<> requestHeaders,
> Cookie). I
absolutely
> agree that this would be very hacky. And it might be dangerous as
> CookieProcessor is an interface and there already might be custom
> implementations.

We can fix that with default implementations, for Java versions that
support such thing (Java >= 1.8).

> But can you think of another way of making the cookie generation
> logic aware of the user agent header value?

Not really.

I have a preference for:

CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)

This is because User-Agent might not be the only header which is
useful, here. For example, Google Chrome (amusingly enough) will be
removing the User-Agent header[1] in favor of "client hints"[2].

So you might have to look at more than one header at a time, including
possibly User-Agent.

- -chris

[1]
https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-
chrome/

[2] https://wicg.github.io/ua-client-hints/

> On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Lazar,
>
> On 2/14/20 05:36, Lazar Kirchev wrote:
 Chris,

 Just FYI or in case someone else hits this problem.

 Actually I had to use the response wrapper approach for
 Tomcat 8.5.50 as well. As described by Chrome in
 https://www.chromium.org/updates/same-site/incompatible-clients,


there are older browser versions which do not support the SameSite
 attribute at all and reject the cookies which contain it.
 Although Tomcat 8.5.42 and later provide the CookieProcessor
 configuration for the SameSite attribute, it is a problem if
 one wants to support older browser versions as well.
> Wow, what a huge pain in the neck. I don't see anything in RFC
> 6265 that says anything about rejecting cookies with unknown
> attributes, but I also don't see anything prohibiting that
> behavior, either. Than again, RFC 6265 doesn't mention the SameSite
> attribute at all, so ... there is that.
>
> This is what you get when vendors try to implement standards
> before they are standards.
>
 Adding the SameSite attribute in order to support newest
 Chrome breaks the old ones as the configuration via the
 CookieProcessor does not allow for user agent sniffing. Even
 if you extend the existing CookieProcessor implementations or
 create your own, you cannot get the request headers in it so
 that you can check for the browser version. If one needs such
 flexibility, only the response wrapper helps. Do you think
 that it makes sense to provide a mechanism in the
 CookieProcessor to get access to the request headers in order
 to check the user agent?
> Are you referring to CookieProcessor.generateCookie(Cookie)? So
> the proposal would be to change that to
> CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe
> even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)?
>
> It seems super hacky to do it that way, but I'm not sure I see
> another option for introducing SameSite in a compatible way.
>
> -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/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5QEJgACgkQHPApP6U8
pFgC6w/7BzMCRdeR4Kldjigj6R48AUWcUorN0R1tQu4pxOT04DWPPkC+qXWoCtkT
MNB3VgAuqjPnNLUDaGskvhU73p4lGqa2Z2scFKfS7CjTDs/cgwTusl+/bHqynK1P
zxea0tU5DQvVUNbo5tvfWhwzoE/7/5lCcevkmBIwinktNr7+tOygIFvJl0vR7g5J
diXmOlG0ratoGcbxr6qCzb/X3q7aUwn2U/m3yakX6HXcWg4tbOeVX969w5NU4i7c
G+u5I+ayMqZt4DOU/5izuknsBUtvTEn36INoYaUmlK72KZofh9MOU56dSE/lyyPd
snL493LHkgnCjpA8Se4GDHEV/TUqvn1/c0sSRzf6dMgwnE2w61VtJVzDstklWhWW
0S9GoTb+yi89QLcCPSJA2ZWiS2kbPMnEPqxgHTFwkhnqKpyjr9hw4h5O4Qr6fLYs
bD8QihLWvyjoa4ImpIQZ3n+6556OEGYg6fUO/RKlx3cLB7nplsXUr0IxpE3XFW9T
iV4ZaiZHtT+CtrDVqy2DO1kzj5GAxaoUWTXsDN4sqCwvJnAUId1rBpz0B1yZPPQh
vPB3z6E1RmfOynY1ZWI+i3oJDd02ytsKsfnMaOYcYe8jE3WIsjvoCbzEQLr5nOQR
YBSm40NqgJt3Obb2w/5IuFzgTSLyIpy8wIopYIUSmI1qhTDSEZQ=
=mZj/
-END PGP SIGNATURE-

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

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Yes, the SameSite attribute is still in a draft and this causes the mess,
at least partly.

And yes, I was thinking about something like that -
CookieProcessor.generateCookie(String userAgent, Cookie) or
CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). I absolutely
agree that this would be very hacky. And it might be dangerous as
CookieProcessor is an interface and there already might be custom
implementations.
But can you think of another way of making the cookie generation logic
aware of the user agent header value?

Lazar

On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 2/14/20 05:36, Lazar Kirchev wrote:
> > Chris,
> >
> > Just FYI or in case someone else hits this problem.
> >
> > Actually I had to use the response wrapper approach for Tomcat
> > 8.5.50 as well. As described by Chrome in
> > https://www.chromium.org/updates/same-site/incompatible-clients,
> > there are older browser versions which do not support the SameSite
> >  attribute at all and reject the cookies which contain it. Although
> >  Tomcat 8.5.42 and later provide the CookieProcessor configuration
> > for the SameSite attribute, it is a problem if one wants to
> > support older browser versions as well.
> Wow, what a huge pain in the neck. I don't see anything in RFC 6265
> that says anything about rejecting cookies with unknown attributes,
> but I also don't see anything prohibiting that behavior, either. Than
> again, RFC 6265 doesn't mention the SameSite attribute at all, so ...
> there is that.
>
> This is what you get when vendors try to implement standards before
> they are standards.
>
> > Adding the SameSite attribute in order to support newest Chrome
> > breaks the old ones as the configuration via the CookieProcessor
> > does not allow for user agent sniffing. Even if you extend the
> > existing CookieProcessor implementations or create your own, you
> > cannot get the request headers in it so that you can check for the
> > browser version. If one needs such flexibility, only the response
> > wrapper helps. Do you think that it makes sense to provide a
> > mechanism in the CookieProcessor to get access to the request
> > headers in order to check the user agent?
> Are you referring to CookieProcessor.generateCookie(Cookie)? So the
> proposal would be to change that to
> CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe
> even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)?
>
> It seems super hacky to do it that way, but I'm not sure I see another
> option for introducing SameSite in a compatible way.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5G7hcACgkQHPApP6U8
> pFhBGg//fPcTiL5fYRfVKB7IbRe/T43UNIVzWYugujVQnJTP+owJnQvSXXPhvQgB
> jJNNvuIyiqw03Z4EpychSaq9r0f1YHsp7cVkScu+vRPXR5B70Ny4vzSf0sNrFXSz
> K2pDBIE7FlxhmBjdXaIAZbcmZKPQKbcpUWes898Ichh4XlBl5Ij2ZGYf86jENsoB
> dFSc+pyMHjDrGilUcCDi6VNthJauB0JegTpm7Iwh1zJ64u9LgAcxHmfVkpz1RVUD
> bL+c/WmEPBET1ebYy3tBmJXXbdqmDzJbMubYJYe5uDi1cseUmhiUhhk0I5M/DSeo
> CCLelrHCcD8JJ049aLNOFXLNgiUquoe+zFlqlecNxI+6LzOEPUeYHCiAg6XqKggx
> uCxcjEq6RTP8xHfRsVgk1r9X0pS/Zjhp9EPAN9LUc+QoC0MW8+ZwgsnSrIXVOfPa
> Ln+NV+3Ve3F3vBi+apdoCq2U5I1K2Q0YYGiZyHknIWfqXtM1jycylcn2F0YZ/VMn
> l1E6tkOb2owdnf6QJkcWibFFiEpWZqj9PsOipj/IQBaBAYOW4wMK6q2USU6reNGK
> IjQ3aWJjPOaHSfqCPlxeAUW8lIsHkgtjJmX4zzXEOOpgIulMWzpDX8Ia1ItXLqVH
> HPdI0j9I+Dl9tjRhLyy1FL2M7WNPFLhBD9qhJ9Eeli8SCtIAEzc=
> =tR3G
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 2/14/20 05:36, Lazar Kirchev wrote:
> Chris,
>
> Just FYI or in case someone else hits this problem.
>
> Actually I had to use the response wrapper approach for Tomcat
> 8.5.50 as well. As described by Chrome in
> https://www.chromium.org/updates/same-site/incompatible-clients,
> there are older browser versions which do not support the SameSite
>  attribute at all and reject the cookies which contain it. Although
>  Tomcat 8.5.42 and later provide the CookieProcessor configuration
> for the SameSite attribute, it is a problem if one wants to
> support older browser versions as well.
Wow, what a huge pain in the neck. I don't see anything in RFC 6265
that says anything about rejecting cookies with unknown attributes,
but I also don't see anything prohibiting that behavior, either. Than
again, RFC 6265 doesn't mention the SameSite attribute at all, so ...
there is that.

This is what you get when vendors try to implement standards before
they are standards.

> Adding the SameSite attribute in order to support newest Chrome
> breaks the old ones as the configuration via the CookieProcessor
> does not allow for user agent sniffing. Even if you extend the
> existing CookieProcessor implementations or create your own, you
> cannot get the request headers in it so that you can check for the
> browser version. If one needs such flexibility, only the response
> wrapper helps. Do you think that it makes sense to provide a
> mechanism in the CookieProcessor to get access to the request
> headers in order to check the user agent?
Are you referring to CookieProcessor.generateCookie(Cookie)? So the
proposal would be to change that to
CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe
even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)?

It seems super hacky to do it that way, but I'm not sure I see another
option for introducing SameSite in a compatible way.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5G7hcACgkQHPApP6U8
pFhBGg//fPcTiL5fYRfVKB7IbRe/T43UNIVzWYugujVQnJTP+owJnQvSXXPhvQgB
jJNNvuIyiqw03Z4EpychSaq9r0f1YHsp7cVkScu+vRPXR5B70Ny4vzSf0sNrFXSz
K2pDBIE7FlxhmBjdXaIAZbcmZKPQKbcpUWes898Ichh4XlBl5Ij2ZGYf86jENsoB
dFSc+pyMHjDrGilUcCDi6VNthJauB0JegTpm7Iwh1zJ64u9LgAcxHmfVkpz1RVUD
bL+c/WmEPBET1ebYy3tBmJXXbdqmDzJbMubYJYe5uDi1cseUmhiUhhk0I5M/DSeo
CCLelrHCcD8JJ049aLNOFXLNgiUquoe+zFlqlecNxI+6LzOEPUeYHCiAg6XqKggx
uCxcjEq6RTP8xHfRsVgk1r9X0pS/Zjhp9EPAN9LUc+QoC0MW8+ZwgsnSrIXVOfPa
Ln+NV+3Ve3F3vBi+apdoCq2U5I1K2Q0YYGiZyHknIWfqXtM1jycylcn2F0YZ/VMn
l1E6tkOb2owdnf6QJkcWibFFiEpWZqj9PsOipj/IQBaBAYOW4wMK6q2USU6reNGK
IjQ3aWJjPOaHSfqCPlxeAUW8lIsHkgtjJmX4zzXEOOpgIulMWzpDX8Ia1ItXLqVH
HPdI0j9I+Dl9tjRhLyy1FL2M7WNPFLhBD9qhJ9Eeli8SCtIAEzc=
=tR3G
-END PGP SIGNATURE-

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

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

Just FYI or in case someone else hits this problem.

Actually I had to use the response wrapper approach for Tomcat 8.5.50 as
well. As described by Chrome in
https://www.chromium.org/updates/same-site/incompatible-clients, there are
older browser versions which do not support the SameSite attribute at all
and reject the cookies which contain it. Although Tomcat 8.5.42 and later
provide the CookieProcessor configuration for the SameSite attribute, it is
a problem if one wants to support older browser versions as well. Adding
the SameSite attribute in order to support newest Chrome breaks the old
ones as the configuration via the CookieProcessor does not allow for user
agent sniffing. Even if you extend the existing CookieProcessor
implementations or create your own, you cannot get the request headers in
it so that you can check for the browser version. If one needs such
flexibility, only the response wrapper helps.
Do you think that it makes sense to provide a mechanism in the
CookieProcessor to get access to the request headers in order to check the
user agent?

Kind regards,
Lazar

On Tue, Feb 4, 2020 at 5:54 PM Lazar Kirchev 
wrote:

> Thanks a lot Chris! I wish I could just get away from Tomcat 7 and upgrade
> to 8.5, but I can't. Yes, the response wrapping will do.
>
> Lazar
>
> On Mon, Feb 3, 2020 at 4:30 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Lazar,
>>
>> On 2/3/20 5:42 AM, Lazar Kirchev wrote:
>> > Chris,
>> >
>> > With "having control on the server but not on the application" I
>> > meant that I could make changes on the server, but I have no
>> > control to make modification on the application code. My concern
>> > with the changed Chrome behavior regarding the same site cookie
>> > attribute (https://www.chromestatus.com/feature/5088147346030592)
>> > is that assuming "lax" as default value of the same site attribute
>> > would break some specific authentication scenarios. Here I am
>> > concerned particularly with the same site attribute of the
>> > JSESSIONID cookie.
>>
>> Do you need your JSESSIONIDs to be sent to domains other than the one
>> where the application actually lives? The whole same-site thing exists
>> to fix some corner-cases in cookie theft. A "typical" application
>> should not need any intervention, I think.
>>
>> > In a valve I can modify a header when the valve is invoked and
>> > before it calls the next valve in the chain, but at that time the
>> > JSESSIONID cookie may not be issued yet.
>>
>> There are other options.
>>
>> > And when the control comes back to the valve on the way back it may
>> > be too late to change the header value.
>>
>> There are other options.
>>
>> > In Tomcat 8 and above the same site attribute can be specified as
>> > a configuration to the CookieProcessor implementation. Is it
>> > possible to achieve this reliably in Tomcat 7?
>>
>> Not with Tomcat's code. This does not appear to have been back-ported.
>>
>> I think you have two options:
>>
>> 1. Upgrade to Tomcat 8.5 (it's less painful than you might think)
>>
>> 2. Write a Valve and install it in the application:
>>  - For each request
>> a. Wrap the response object in a wrapper class you write
>> b. Dispatch the request as usual, using your response wrapper
>>  - Your wrapper class should:
>> a. Extend o.a.c.connector.Response
>> b. Override generateCookieString(Cookie)
>> c. Call the superclass method, mutate as necessary
>> d. Return the massaged cookie string
>>
>> I'm not sure which of those you consider riskier for your environment.
>> You are cutting it a little close (chrome 80 is scheduled to be stable
>> tomorrow).
>>
>> - -chris
>>
>> > Lazar,
>> >
>> > On 1/30/20 12:25 PM, Lazar Kirchev wrote:
>>  The problem is that I cannot make it from within the
>>  application. I have no control on the application, only on
>>  the server, so I have to be able to set the cookie either in
>>  a server configuration or in a component which will reside in
>>  the server.
>> >
>> > It's not clear to me what you mean by "server". Usually, the
>> > application runs on the server, so if you only have control of the
>> > server... you have control of the application.
>> >
>>  I am concerned particularly with the SameSite attribute of
>>  the JSESSIONID cookie because of the new behavior of Chrome
>>  80 - https://www.chromestatus.com/feature/5088147346030592
>> >
>> > What is your specific concern?
>> >
>>  I was considering to have a valve which modifies the
>>  Set-Cookie header. But I if the application flushes the
>>  output stream the headers will be written to the socket and
>>  the valve will not have the chance to modify the cookie.
>> > You can use a  which can intercept the calls to
>> > setHeader(), etc. to correct the header value.
>> >
>> > Which cookie are you trying to modify?
>> >
>> > -chris
>> >
>>  On Tue, Jan 28

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Thanks a lot Chris! I wish I could just get away from Tomcat 7 and upgrade
to 8.5, but I can't. Yes, the response wrapping will do.

Lazar

On Mon, Feb 3, 2020 at 4:30 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 2/3/20 5:42 AM, Lazar Kirchev wrote:
> > Chris,
> >
> > With "having control on the server but not on the application" I
> > meant that I could make changes on the server, but I have no
> > control to make modification on the application code. My concern
> > with the changed Chrome behavior regarding the same site cookie
> > attribute (https://www.chromestatus.com/feature/5088147346030592)
> > is that assuming "lax" as default value of the same site attribute
> > would break some specific authentication scenarios. Here I am
> > concerned particularly with the same site attribute of the
> > JSESSIONID cookie.
>
> Do you need your JSESSIONIDs to be sent to domains other than the one
> where the application actually lives? The whole same-site thing exists
> to fix some corner-cases in cookie theft. A "typical" application
> should not need any intervention, I think.
>
> > In a valve I can modify a header when the valve is invoked and
> > before it calls the next valve in the chain, but at that time the
> > JSESSIONID cookie may not be issued yet.
>
> There are other options.
>
> > And when the control comes back to the valve on the way back it may
> > be too late to change the header value.
>
> There are other options.
>
> > In Tomcat 8 and above the same site attribute can be specified as
> > a configuration to the CookieProcessor implementation. Is it
> > possible to achieve this reliably in Tomcat 7?
>
> Not with Tomcat's code. This does not appear to have been back-ported.
>
> I think you have two options:
>
> 1. Upgrade to Tomcat 8.5 (it's less painful than you might think)
>
> 2. Write a Valve and install it in the application:
>  - For each request
> a. Wrap the response object in a wrapper class you write
> b. Dispatch the request as usual, using your response wrapper
>  - Your wrapper class should:
> a. Extend o.a.c.connector.Response
> b. Override generateCookieString(Cookie)
> c. Call the superclass method, mutate as necessary
> d. Return the massaged cookie string
>
> I'm not sure which of those you consider riskier for your environment.
> You are cutting it a little close (chrome 80 is scheduled to be stable
> tomorrow).
>
> - -chris
>
> > Lazar,
> >
> > On 1/30/20 12:25 PM, Lazar Kirchev wrote:
>  The problem is that I cannot make it from within the
>  application. I have no control on the application, only on
>  the server, so I have to be able to set the cookie either in
>  a server configuration or in a component which will reside in
>  the server.
> >
> > It's not clear to me what you mean by "server". Usually, the
> > application runs on the server, so if you only have control of the
> > server... you have control of the application.
> >
>  I am concerned particularly with the SameSite attribute of
>  the JSESSIONID cookie because of the new behavior of Chrome
>  80 - https://www.chromestatus.com/feature/5088147346030592
> >
> > What is your specific concern?
> >
>  I was considering to have a valve which modifies the
>  Set-Cookie header. But I if the application flushes the
>  output stream the headers will be written to the socket and
>  the valve will not have the chance to modify the cookie.
> > You can use a  which can intercept the calls to
> > setHeader(), etc. to correct the header value.
> >
> > Which cookie are you trying to modify?
> >
> > -chris
> >
>  On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  John,
> 
>  On 1/27/20 9:37 AM, John Dale wrote:
> >>> Over the years I found it more productive to manage my
> >>> own headers for the most part.
> >>>
> >>> The key for us has been keeping the code clean and
> >>> manageable.
> 
>  +1
> 
>  But there isn't any reason not to use Tomcat's header
>  parsing. If you have anything that could be considered odd,
>  you should encode it in a safe way that doesn't require that
>  you play other games with the cookie value.
> 
>  For example, base64 encoding a cookie value should make it
>  header-safe, as long as you make sure to use a base64 encoder
>  that doesn't add newlines.
> 
>  -chris
> 
> >>> On 1/27/20, Lazar Kirchev 
> >>> wrote:
>  Hello,
> 
>  In Tomcat >= 8 there is the CookieProcessor in which
>  cookie configurations could be made, including for
>  SameSite cookie. Is there any way to configure this
>  in Tomcat 7? Or the only way is to configure it
>  manually in code?
> 
>  Kind regards, Lazar
> 
> >>>
> >>> 

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 2/3/20 5:42 AM, Lazar Kirchev wrote:
> Chris,
> 
> With "having control on the server but not on the application" I
> meant that I could make changes on the server, but I have no
> control to make modification on the application code. My concern
> with the changed Chrome behavior regarding the same site cookie 
> attribute (https://www.chromestatus.com/feature/5088147346030592)
> is that assuming "lax" as default value of the same site attribute
> would break some specific authentication scenarios. Here I am
> concerned particularly with the same site attribute of the
> JSESSIONID cookie.

Do you need your JSESSIONIDs to be sent to domains other than the one
where the application actually lives? The whole same-site thing exists
to fix some corner-cases in cookie theft. A "typical" application
should not need any intervention, I think.

> In a valve I can modify a header when the valve is invoked and
> before it calls the next valve in the chain, but at that time the
> JSESSIONID cookie may not be issued yet.

There are other options.

> And when the control comes back to the valve on the way back it may
> be too late to change the header value.

There are other options.

> In Tomcat 8 and above the same site attribute can be specified as
> a configuration to the CookieProcessor implementation. Is it
> possible to achieve this reliably in Tomcat 7?

Not with Tomcat's code. This does not appear to have been back-ported.

I think you have two options:

1. Upgrade to Tomcat 8.5 (it's less painful than you might think)

2. Write a Valve and install it in the application:
 - For each request
a. Wrap the response object in a wrapper class you write
b. Dispatch the request as usual, using your response wrapper
 - Your wrapper class should:
a. Extend o.a.c.connector.Response
b. Override generateCookieString(Cookie)
c. Call the superclass method, mutate as necessary
d. Return the massaged cookie string

I'm not sure which of those you consider riskier for your environment.
You are cutting it a little close (chrome 80 is scheduled to be stable
tomorrow).

- -chris

> Lazar,
> 
> On 1/30/20 12:25 PM, Lazar Kirchev wrote:
 The problem is that I cannot make it from within the
 application. I have no control on the application, only on
 the server, so I have to be able to set the cookie either in
 a server configuration or in a component which will reside in
 the server.
> 
> It's not clear to me what you mean by "server". Usually, the 
> application runs on the server, so if you only have control of the 
> server... you have control of the application.
> 
 I am concerned particularly with the SameSite attribute of
 the JSESSIONID cookie because of the new behavior of Chrome
 80 - https://www.chromestatus.com/feature/5088147346030592
> 
> What is your specific concern?
> 
 I was considering to have a valve which modifies the
 Set-Cookie header. But I if the application flushes the
 output stream the headers will be written to the socket and
 the valve will not have the chance to modify the cookie.
> You can use a  which can intercept the calls to
> setHeader(), etc. to correct the header value.
> 
> Which cookie are you trying to modify?
> 
> -chris
> 
 On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 John,
 
 On 1/27/20 9:37 AM, John Dale wrote:
>>> Over the years I found it more productive to manage my
>>> own headers for the most part.
>>> 
>>> The key for us has been keeping the code clean and 
>>> manageable.
 
 +1
 
 But there isn't any reason not to use Tomcat's header
 parsing. If you have anything that could be considered odd,
 you should encode it in a safe way that doesn't require that
 you play other games with the cookie value.
 
 For example, base64 encoding a cookie value should make it 
 header-safe, as long as you make sure to use a base64 encoder
 that doesn't add newlines.
 
 -chris
 
>>> On 1/27/20, Lazar Kirchev 
>>> wrote:
 Hello,
 
 In Tomcat >= 8 there is the CookieProcessor in which 
 cookie configurations could be made, including for
 SameSite cookie. Is there any way to configure this
 in Tomcat 7? Or the only way is to configure it
 manually in code?
 
 Kind regards, Lazar
 
>>> 
>>> 
- ---
>>
>>
>>> 
- -
>> 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/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44LokACgkQ

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris,

With "having control on the server but not on the application" I meant that
I could make changes on the server, but I have no control to make
modification on the application code.
My concern with the changed Chrome behavior regarding the same site cookie
attribute (https://www.chromestatus.com/feature/5088147346030592) is that
assuming "lax" as default value of the same site attribute would break some
specific authentication scenarios. Here I am concerned particularly with
the same site attribute of the JSESSIONID cookie.
In a valve I can modify a header when the valve is invoked and before it
calls the next valve in the chain, but at that time the JSESSIONID cookie
may not be issued yet. And when the control comes back to the valve on the
way back it may be too late to change the header value.
In Tomcat 8 and above the same site attribute can be specified as a
configuration to the CookieProcessor implementation. Is it possible to
achieve this reliably in Tomcat 7?

Lazar

On Fri, Jan 31, 2020 at 6:03 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 1/30/20 12:25 PM, Lazar Kirchev wrote:
> > The problem is that I cannot make it from within the application. I
> > have no control on the application, only on the server, so I have
> > to be able to set the cookie either in a server configuration or in
> > a component which will reside in the server.
>
> It's not clear to me what you mean by "server". Usually, the
> application runs on the server, so if you only have control of the
> server... you have control of the application.
>
> > I am concerned particularly with the SameSite attribute of the
> > JSESSIONID cookie because of the new behavior of Chrome 80 -
> > https://www.chromestatus.com/feature/5088147346030592
>
> What is your specific concern?
>
> > I was considering to have a valve which modifies the Set-Cookie
> > header. But I if the application flushes the output stream the
> > headers will be written to the socket and the valve will not have
> > the chance to modify the cookie.
> You can use a  which can intercept the calls to setHeader(),
> etc. to correct the header value.
>
> Which cookie are you trying to modify?
>
> - -chris
>
> > On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > John,
> >
> > On 1/27/20 9:37 AM, John Dale wrote:
>  Over the years I found it more productive to manage my own
>  headers for the most part.
> 
>  The key for us has been keeping the code clean and
>  manageable.
> >
> > +1
> >
> > But there isn't any reason not to use Tomcat's header parsing. If
> > you have anything that could be considered odd, you should encode
> > it in a safe way that doesn't require that you play other games
> > with the cookie value.
> >
> > For example, base64 encoding a cookie value should make it
> > header-safe, as long as you make sure to use a base64 encoder that
> > doesn't add newlines.
> >
> > -chris
> >
>  On 1/27/20, Lazar Kirchev  wrote:
> > Hello,
> >
> > In Tomcat >= 8 there is the CookieProcessor in which
> > cookie configurations could be made, including for SameSite
> > cookie. Is there any way to configure this in Tomcat 7? Or
> > the only way is to configure it manually in code?
> >
> > Kind regards, Lazar
> >
> 
>  ---
> - --
> 
> 
> >
> 
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail:
>  users-h...@tomcat.apache.org
> 
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl40T9gACgkQHPApP6U8
> pFhtmxAAgbipkJUvbAl5RkPw0/F2jXhUD03TRqD1fouMaVDWx+FcbhbMXxcrYQpA
> XYvkRZKj2xbpaKz1Kmy0dSTwBTlJU2ZC8/ZosxGC8c0MBqXyEgxdC0/1zPN0u03j
> Oa/L8nl+MNlHcA9OFtj8JoDg3VQmoJ86wsqNGtVEJa6M6lJoxnPLp7asFbJwWjGR
> jHqG6kbeDZFvuJbZ1KraKntPA4bYB3tutil5QBzVhu/jb7gn7pXnZW24Jxk/Qg5p
> vufLshRUsBfhHqSTw1GBiDlzcNmvZov2ZNfj92wVqiofu82/AKVjmWJ/n3ogie12
> boxX29Jkbir2k6+/Pd4VquAxNTxdLYliENhNsvWuMTclRf1vzszt2WL7C/lwn25S
> EOWVTLTiujxHt6kzj/1tFlhpnijF+MNCulD8LuZ/IX4hEP+eqb0Dk+B/87yYRlA/
> UkigrhgRb0+ooMijewnjBy67mZl1Hdgim193DKrt89fjRKbLo8TAW6nLRzcnNKdu
> BzzewqW7L2WHwHnt+v05s38yCw+hUkqxqBh8Vfw68EmQQAXmMQsF+lp5By//2g+X
> LWth0k0YjuYU+JcROKr/VSfByBs5VnveuNctQEZmxfqO6s8DjnrsfQdz6FnOZ9xd
> 2QuRWjgUjKMFB8j+V9z+pC6C5fjN+YP/c4LXO+KMQ5KwJh5YksQ=
> =cHov
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-ma

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 1/30/20 12:25 PM, Lazar Kirchev wrote:
> The problem is that I cannot make it from within the application. I
> have no control on the application, only on the server, so I have
> to be able to set the cookie either in a server configuration or in
> a component which will reside in the server.

It's not clear to me what you mean by "server". Usually, the
application runs on the server, so if you only have control of the
server... you have control of the application.

> I am concerned particularly with the SameSite attribute of the
> JSESSIONID cookie because of the new behavior of Chrome 80 -
> https://www.chromestatus.com/feature/5088147346030592

What is your specific concern?

> I was considering to have a valve which modifies the Set-Cookie 
> header. But I if the application flushes the output stream the 
> headers will be written to the socket and the valve will not have
> the chance to modify the cookie.
You can use a  which can intercept the calls to setHeader(),
etc. to correct the header value.

Which cookie are you trying to modify?

- -chris

> On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> John,
> 
> On 1/27/20 9:37 AM, John Dale wrote:
 Over the years I found it more productive to manage my own
 headers for the most part.
 
 The key for us has been keeping the code clean and
 manageable.
> 
> +1
> 
> But there isn't any reason not to use Tomcat's header parsing. If
> you have anything that could be considered odd, you should encode
> it in a safe way that doesn't require that you play other games
> with the cookie value.
> 
> For example, base64 encoding a cookie value should make it 
> header-safe, as long as you make sure to use a base64 encoder that 
> doesn't add newlines.
> 
> -chris
> 
 On 1/27/20, Lazar Kirchev  wrote:
> Hello,
> 
> In Tomcat >= 8 there is the CookieProcessor in which
> cookie configurations could be made, including for SameSite
> cookie. Is there any way to configure this in Tomcat 7? Or
> the only way is to configure it manually in code?
> 
> Kind regards, Lazar
> 
 
 ---
- --


>
 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail:
 users-h...@tomcat.apache.org
 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl40T9gACgkQHPApP6U8
pFhtmxAAgbipkJUvbAl5RkPw0/F2jXhUD03TRqD1fouMaVDWx+FcbhbMXxcrYQpA
XYvkRZKj2xbpaKz1Kmy0dSTwBTlJU2ZC8/ZosxGC8c0MBqXyEgxdC0/1zPN0u03j
Oa/L8nl+MNlHcA9OFtj8JoDg3VQmoJ86wsqNGtVEJa6M6lJoxnPLp7asFbJwWjGR
jHqG6kbeDZFvuJbZ1KraKntPA4bYB3tutil5QBzVhu/jb7gn7pXnZW24Jxk/Qg5p
vufLshRUsBfhHqSTw1GBiDlzcNmvZov2ZNfj92wVqiofu82/AKVjmWJ/n3ogie12
boxX29Jkbir2k6+/Pd4VquAxNTxdLYliENhNsvWuMTclRf1vzszt2WL7C/lwn25S
EOWVTLTiujxHt6kzj/1tFlhpnijF+MNCulD8LuZ/IX4hEP+eqb0Dk+B/87yYRlA/
UkigrhgRb0+ooMijewnjBy67mZl1Hdgim193DKrt89fjRKbLo8TAW6nLRzcnNKdu
BzzewqW7L2WHwHnt+v05s38yCw+hUkqxqBh8Vfw68EmQQAXmMQsF+lp5By//2g+X
LWth0k0YjuYU+JcROKr/VSfByBs5VnveuNctQEZmxfqO6s8DjnrsfQdz6FnOZ9xd
2QuRWjgUjKMFB8j+V9z+pC6C5fjN+YP/c4LXO+KMQ5KwJh5YksQ=
=cHov
-END PGP SIGNATURE-

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

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

The problem is that I cannot make it from within the application. I have no
control on the application, only on the server, so I have to be able to set
the cookie either in a server configuration or in a component which will
reside in the server. I am concerned particularly with the SmaeSite
attribute of the JSESSIONID cookie because of the new behavior of Chrome 80
-  https://www.chromestatus.com/feature/5088147346030592. I was considering
to have a valve which modifies the Set-Cookie header. But I if the
application flushes the output stream the headers will be written to the
socket and the valve will not have the chance to modify the cookie.

Lazar

On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 1/27/20 9:37 AM, John Dale wrote:
> > Over the years I found it more productive to manage my own headers
> > for the most part.
> >
> > The key for us has been keeping the code clean and manageable.
>
> +1
>
> But there isn't any reason not to use Tomcat's header parsing. If you
> have anything that could be considered odd, you should encode it in a
> safe way that doesn't require that you play other games with the
> cookie value.
>
> For example, base64 encoding a cookie value should make it
> header-safe, as long as you make sure to use a base64 encoder that
> doesn't add newlines.
>
> - -chris
>
> > On 1/27/20, Lazar Kirchev  wrote:
> >> Hello,
> >>
> >> In Tomcat >= 8 there is the CookieProcessor in which cookie
> >> configurations could be made, including for SameSite cookie. Is
> >> there any way to configure this in Tomcat 7? Or the only way is
> >> to configure it manually in code?
> >>
> >> Kind regards, Lazar
> >>
> >
> > -
> >
> >
> 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/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wUtwACgkQHPApP6U8
> pFi+NRAAhLyyE3tQuxUnkDEfBWD/myhclfgBtij85I/ovcYKqG1vZ13k4il4Ti2u
> eybk7C59WXnoaoiCL59JU/fC3a+p/hnK404FEH51iQ6TybSOC4BQjrzojiDCKSgi
> w0enCMkmbrEJNAYmg9SH4aqtet1tbxSMTjvEwHCxog3W1LEFeB2GXz9zvxyUQ82m
> Z1cSVjPn0sgzlV1UwABJnnxxveke2oH+CXpNtWR4eY/EjO3aC/sHfHJPyxNGFfUy
> xiT+S8Mv5K53M5Uz4+CGDIUWpu1/IwhRCtrS4FynMgm+l+ukPkdh96tlEfHx4mUF
> k+qo7vLcpq674QyYfPw94vRJ2BolwnoEtvPpIpNGa96QP1otP5WbJo+msr49pa/h
> +KLVw/nByH6+lv/K/Zt2bL/emKwoc+0Zb7eqEdJnOPBMXyXlSqoU5XHxpc6UFNA/
> zCjXCRV/A0pXuHZDFXpjKS0tnwDj7fUsPuHHK8kol10ZhjZ672NLoXt5sFMiqXk9
> tWk2bnUfTxxJaO13g86bIKLIch2UiSw2Dtg3qtbEHjm1VxTEscaJnFkX5I606x2d
> LW9dNhnBG4bEOt22sCb+iI5duw5HezDPVNUN4AsHizu3bZQlJIt/dOHJFXppyCfm
> 53+tZGs9veAG8Vlz3/DbLdTod92pxX6gGbmjJsU3TonPc4mMdNY=
> =UIAx
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 1/27/20 9:37 AM, John Dale wrote:
> Over the years I found it more productive to manage my own headers
> for the most part.
> 
> The key for us has been keeping the code clean and manageable.

+1

But there isn't any reason not to use Tomcat's header parsing. If you
have anything that could be considered odd, you should encode it in a
safe way that doesn't require that you play other games with the
cookie value.

For example, base64 encoding a cookie value should make it
header-safe, as long as you make sure to use a base64 encoder that
doesn't add newlines.

- -chris

> On 1/27/20, Lazar Kirchev  wrote:
>> Hello,
>> 
>> In Tomcat >= 8 there is the CookieProcessor in which cookie
>> configurations could be made, including for SameSite cookie. Is
>> there any way to configure this in Tomcat 7? Or the only way is
>> to configure it manually in code?
>> 
>> Kind regards, Lazar
>> 
> 
> -
>
> 
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/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wUtwACgkQHPApP6U8
pFi+NRAAhLyyE3tQuxUnkDEfBWD/myhclfgBtij85I/ovcYKqG1vZ13k4il4Ti2u
eybk7C59WXnoaoiCL59JU/fC3a+p/hnK404FEH51iQ6TybSOC4BQjrzojiDCKSgi
w0enCMkmbrEJNAYmg9SH4aqtet1tbxSMTjvEwHCxog3W1LEFeB2GXz9zvxyUQ82m
Z1cSVjPn0sgzlV1UwABJnnxxveke2oH+CXpNtWR4eY/EjO3aC/sHfHJPyxNGFfUy
xiT+S8Mv5K53M5Uz4+CGDIUWpu1/IwhRCtrS4FynMgm+l+ukPkdh96tlEfHx4mUF
k+qo7vLcpq674QyYfPw94vRJ2BolwnoEtvPpIpNGa96QP1otP5WbJo+msr49pa/h
+KLVw/nByH6+lv/K/Zt2bL/emKwoc+0Zb7eqEdJnOPBMXyXlSqoU5XHxpc6UFNA/
zCjXCRV/A0pXuHZDFXpjKS0tnwDj7fUsPuHHK8kol10ZhjZ672NLoXt5sFMiqXk9
tWk2bnUfTxxJaO13g86bIKLIch2UiSw2Dtg3qtbEHjm1VxTEscaJnFkX5I606x2d
LW9dNhnBG4bEOt22sCb+iI5duw5HezDPVNUN4AsHizu3bZQlJIt/dOHJFXppyCfm
53+tZGs9veAG8Vlz3/DbLdTod92pxX6gGbmjJsU3TonPc4mMdNY=
=UIAx
-END PGP SIGNATURE-

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

Re: cookie configurations for Tomcat 7

[John Dale]

Over the years I found it more productive to manage my own headers for
the most part.

The key for us has been keeping the code clean and manageable.

John


On 1/27/20, Lazar Kirchev  wrote:
> Hello,
>
> In Tomcat >= 8 there is the CookieProcessor in which cookie configurations
> could be made, including for SameSite cookie.
> Is there any way to configure this in Tomcat 7? Or the only way is to
> configure it manually in code?
>
> Kind regards,
> Lazar
>

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

cookie configurations for Tomcat 7

[Lazar Kirchev]

Hello,

In Tomcat >= 8 there is the CookieProcessor in which cookie configurations
could be made, including for SameSite cookie.
Is there any way to configure this in Tomcat 7? Or the only way is to
configure it manually in code?

Kind regards,
Lazar