cookie configurations for Tomcat 7

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cookie configurations for Tomcat 7

Christopher Schultz-2
-----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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <
[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> -----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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: cookie configurations for Tomcat 7

Christopher Schultz-2
-----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 <Valve> 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 <
> [hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail:
>>>> [hidden email]
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <
[hidden email]> 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 <Valve> 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 <
> > [hidden email]> 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 <[hidden email]> 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: [hidden email]
> >>>> For additional commands, e-mail:
> >>>> [hidden email]
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> -----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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: cookie configurations for Tomcat 7

Christopher Schultz-2
-----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 <Valve> 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 <
>>>> [hidden email]> 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 <[hidden email]>
>>>>>>> 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: [hidden email] For
>> additional commands, e-mail: [hidden email]
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44LokACgkQHPApP6U8
pFjIyQ/9GGUXZZX//bAStwgisWYLecElE61d01I7+hRwWMS1NvbBPSZ+rQ7EE1KV
wojDvdIjcSk5krz4jKcA3OXSZv/lAmpACCSydKs6V07FJkV8jBn4Hb1+8sA5/RmA
/qfVXoN+uWDelcxazEtNZzje0I5tGyQ1Cfv2qCKly2uKmIlsy2Fs5cDqLF8phP2Z
GzzgeV4bHW+uwTC78z6sTUdclmGDsCF7sk1/Jmttv8XkvEAHhbXPcPK0rwxcBr5s
R8PLUzJ+9YDfj2Q7KAa6uSYKx3s1KvH7XlIc9xnVsOE45LGhU9a6jMAetOmF3mNT
GGos+LzcNiYNEtUWGG9kbQZHS0sogjQbHNhTwCZvlNx+N3oaNeGtGlfX2SgIbA2I
NacG/31UNEu6uGhC/rh0sP0kA3eadQw/hy9ayeu6BdwpsSVgCMb45T0MpuW9FCbV
CSwtLUX3I3cGHkst+w9zqFMhEktuBazg9lC2juGOTxK+8oTjTlk4bUfb2clDbYmW
s0I8KK/ZfK5Vf1hgbZHIL/JfotFh79ROYNtUEEzaFlCMzxtdVqYTfb1A97ekboBl
nsOgPVcpAPUF0loUBykYDOLh1xQ764MjrlEzcgDoQOUfvO/B99NuWI49S53iti/a
HKIScIjRykysE2M7xOJSCZCPsHz8X8jfzE3QvVXkG1rezx+bw/4=
=Dk7I
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <
[hidden email]> 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 <Valve> 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 <
> >>>> [hidden email]> 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 <[hidden email]>
> >>>>>>> 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: [hidden email] For
> >> additional commands, e-mail: [hidden email]
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44LokACgkQHPApP6U8
> pFjIyQ/9GGUXZZX//bAStwgisWYLecElE61d01I7+hRwWMS1NvbBPSZ+rQ7EE1KV
> wojDvdIjcSk5krz4jKcA3OXSZv/lAmpACCSydKs6V07FJkV8jBn4Hb1+8sA5/RmA
> /qfVXoN+uWDelcxazEtNZzje0I5tGyQ1Cfv2qCKly2uKmIlsy2Fs5cDqLF8phP2Z
> GzzgeV4bHW+uwTC78z6sTUdclmGDsCF7sk1/Jmttv8XkvEAHhbXPcPK0rwxcBr5s
> R8PLUzJ+9YDfj2Q7KAa6uSYKx3s1KvH7XlIc9xnVsOE45LGhU9a6jMAetOmF3mNT
> GGos+LzcNiYNEtUWGG9kbQZHS0sogjQbHNhTwCZvlNx+N3oaNeGtGlfX2SgIbA2I
> NacG/31UNEu6uGhC/rh0sP0kA3eadQw/hy9ayeu6BdwpsSVgCMb45T0MpuW9FCbV
> CSwtLUX3I3cGHkst+w9zqFMhEktuBazg9lC2juGOTxK+8oTjTlk4bUfb2clDbYmW
> s0I8KK/ZfK5Vf1hgbZHIL/JfotFh79ROYNtUEEzaFlCMzxtdVqYTfb1A97ekboBl
> nsOgPVcpAPUF0loUBykYDOLh1xQ764MjrlEzcgDoQOUfvO/B99NuWI49S53iti/a
> HKIScIjRykysE2M7xOJSCZCPsHz8X8jfzE3QvVXkG1rezx+bw/4=
> =Dk7I
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
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 <
> [hidden email]> 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 <Valve> 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 <
>> >>>> [hidden email]> 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 <[hidden email]>
>> >>>>>>> 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: [hidden email] For
>> >> additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44LokACgkQHPApP6U8
>> pFjIyQ/9GGUXZZX//bAStwgisWYLecElE61d01I7+hRwWMS1NvbBPSZ+rQ7EE1KV
>> wojDvdIjcSk5krz4jKcA3OXSZv/lAmpACCSydKs6V07FJkV8jBn4Hb1+8sA5/RmA
>> /qfVXoN+uWDelcxazEtNZzje0I5tGyQ1Cfv2qCKly2uKmIlsy2Fs5cDqLF8phP2Z
>> GzzgeV4bHW+uwTC78z6sTUdclmGDsCF7sk1/Jmttv8XkvEAHhbXPcPK0rwxcBr5s
>> R8PLUzJ+9YDfj2Q7KAa6uSYKx3s1KvH7XlIc9xnVsOE45LGhU9a6jMAetOmF3mNT
>> GGos+LzcNiYNEtUWGG9kbQZHS0sogjQbHNhTwCZvlNx+N3oaNeGtGlfX2SgIbA2I
>> NacG/31UNEu6uGhC/rh0sP0kA3eadQw/hy9ayeu6BdwpsSVgCMb45T0MpuW9FCbV
>> CSwtLUX3I3cGHkst+w9zqFMhEktuBazg9lC2juGOTxK+8oTjTlk4bUfb2clDbYmW
>> s0I8KK/ZfK5Vf1hgbZHIL/JfotFh79ROYNtUEEzaFlCMzxtdVqYTfb1A97ekboBl
>> nsOgPVcpAPUF0loUBykYDOLh1xQ764MjrlEzcgDoQOUfvO/B99NuWI49S53iti/a
>> HKIScIjRykysE2M7xOJSCZCPsHz8X8jfzE3QvVXkG1rezx+bw/4=
>> =Dk7I
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: cookie configurations for Tomcat 7

Christopher Schultz-2
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <
[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: cookie configurations for Tomcat 7

Christopher Schultz-2
-----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 <
> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
-----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: [hidden email]
For additional commands, e-mail: [hidden email]