Improving SameSite support

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

Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

Jakarta EE 5.0 does not appear to include support for SameSite
cookies. Tomcat's CookieProcessor allows an administrator to set the
SameSite cookie policy, but it's a blanket policy.

So for example, if you want a JSESSIONID cookie to be "strict" but
some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever, you
will have to manually-build your "Set-Cookie" headers for your FOO cooki
e.

This is not terribly convenient.

Unfortunately, *any* solution to this problem will be
container-specific. The current Tomcat solution is of course a
solution only for Tomcat, and only for versions which contain that
SameSite support.

I'm wondering if we can do better.

Instead of a single "sameSiteCookies" setting which applies to *all*
cookies, perhaps the CookieProcessor could have a different policy for
specific cookies. Something like this:

<CookieProcessor
className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
sameSiteCookies="unset">
  <SameSiteCookie cookieName="JSESSIONID" policy="strict" />
  <SameSiteCookie cookieName="FOO" policy="lax" />
  ...
</CookieProcessor>

In the above setup, the "sameSiteCookie" attribute of the
CookieProcessor sets the default policy for the CookieProcessor. Then,
each of the <SameSiteCookie> elements sets the policy for a specific
cookie by name.

This would allow applications to set their policies without having to
construct their own Set-Cookie response headers, handle encoding, etc.
and it would also inherit any other Tomcat-supplied cookie-related
policies.

Another option would be to provide a subclass of j.s.h.Cookie which
includes a setSameSite(String) method. The CookieProcessor could check
for instanceof EnhancedCookie (or whatever) and use that setting for
each Cookie object. But that seems like less of a good idea -- except
that it would be easier for refactoring tools to locate instances of
the Tomcat-specific Cookie class and replace them with a future
SameSite-supporting official Jakarta EE Cookie class.

WDYT?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DexAACgkQHPApP6U8
pFjDZBAAiaKBAla3DJ+SHvHTkADOeGXqrMX9kbrIZB3ajnq+m4MEWPH6dmQrg9+j
ROcPVNsj8gahrJSWEzvdu7bQc96tWQ8RD265DQ1pbjwNCfWGHMM8FPJaRp4DO7av
zvWMtNLI/Sv+63CmZr27mzE1o/iJturdNAu/12kOUDd5RVVnM8CROKVtE5rmbVN8
dFQIuMD6mQov+J+Eqg6sqJLPVNoxcjRo25QsrfEOUnsbXx+0sHCe0QMiv4wgMf3G
LnPEY7GhOBOcjaN6lWENAWAkeuoUZIlVpbndk6RRihziSGNAZ+uNORy54mP8SGkR
z33lWKMIolYBBqcmvuFy7OOsfdLGI50kUIc05Hd+T9XMO4p7OSOeJDwvGTmN6Kie
2ZChodQYnWEN//VrD0UxN7t4rlujXF0sS40hryoehzDge/UjVFabR/nEKsySWigR
eddvNhumWqxtjEt8K+/5um366ybVr6VkzpaGfBZ6inzYZtmLmMNr1xd/hz9V5c7j
4KZiGvB5qxZpcrNtmiYJHYzEE8PHauGsEUzG08Skd4SJmo6TkyvefdnaPHezNOse
Ikd78TLvPLNMEE2dUqZ508wYTmR14/ZEiEOt2IUYHD1Dk1oFOgmnR8jbG6+ONZMp
Fjmv5qWfAAeGmWsuMUCHpiz0w3LGJGGlrLur1NXwLkhtz+epx4M=
=dJAO
-----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: Improving SameSite support

Rémy Maucherat
On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

Jakarta EE 5.0 does not appear to include support for SameSite
cookies. Tomcat's CookieProcessor allows an administrator to set the
SameSite cookie policy, but it's a blanket policy.

So for example, if you want a JSESSIONID cookie to be "strict" but
some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever, you
will have to manually-build your "Set-Cookie" headers for your FOO cooki
e.

This is not terribly convenient.

Unfortunately, *any* solution to this problem will be
container-specific. The current Tomcat solution is of course a
solution only for Tomcat, and only for versions which contain that
SameSite support.

I'm wondering if we can do better.

Instead of a single "sameSiteCookies" setting which applies to *all*
cookies, perhaps the CookieProcessor could have a different policy for
specific cookies. Something like this:

<CookieProcessor
className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
sameSiteCookies="unset">
  <SameSiteCookie cookieName="JSESSIONID" policy="strict" />
  <SameSiteCookie cookieName="FOO" policy="lax" />
  ...
</CookieProcessor>

In the above setup, the "sameSiteCookie" attribute of the
CookieProcessor sets the default policy for the CookieProcessor. Then,
each of the <SameSiteCookie> elements sets the policy for a specific
cookie by name.

This would allow applications to set their policies without having to
construct their own Set-Cookie response headers, handle encoding, etc.
and it would also inherit any other Tomcat-supplied cookie-related
policies.

Another option would be to provide a subclass of j.s.h.Cookie which
includes a setSameSite(String) method. The CookieProcessor could check
for instanceof EnhancedCookie (or whatever) and use that setting for
each Cookie object. But that seems like less of a good idea -- except
that it would be easier for refactoring tools to locate instances of
the Tomcat-specific Cookie class and replace them with a future
SameSite-supporting official Jakarta EE Cookie class.

WDYT?

This is a big configuration and API change. Adding a new element is significant, so maybe an expanded syntax could be added to the attribute instead (ex: "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking change though.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DexAACgkQHPApP6U8
pFjDZBAAiaKBAla3DJ+SHvHTkADOeGXqrMX9kbrIZB3ajnq+m4MEWPH6dmQrg9+j
ROcPVNsj8gahrJSWEzvdu7bQc96tWQ8RD265DQ1pbjwNCfWGHMM8FPJaRp4DO7av
zvWMtNLI/Sv+63CmZr27mzE1o/iJturdNAu/12kOUDd5RVVnM8CROKVtE5rmbVN8
dFQIuMD6mQov+J+Eqg6sqJLPVNoxcjRo25QsrfEOUnsbXx+0sHCe0QMiv4wgMf3G
LnPEY7GhOBOcjaN6lWENAWAkeuoUZIlVpbndk6RRihziSGNAZ+uNORy54mP8SGkR
z33lWKMIolYBBqcmvuFy7OOsfdLGI50kUIc05Hd+T9XMO4p7OSOeJDwvGTmN6Kie
2ZChodQYnWEN//VrD0UxN7t4rlujXF0sS40hryoehzDge/UjVFabR/nEKsySWigR
eddvNhumWqxtjEt8K+/5um366ybVr6VkzpaGfBZ6inzYZtmLmMNr1xd/hz9V5c7j
4KZiGvB5qxZpcrNtmiYJHYzEE8PHauGsEUzG08Skd4SJmo6TkyvefdnaPHezNOse
Ikd78TLvPLNMEE2dUqZ508wYTmR14/ZEiEOt2IUYHD1Dk1oFOgmnR8jbG6+ONZMp
Fjmv5qWfAAeGmWsuMUCHpiz0w3LGJGGlrLur1NXwLkhtz+epx4M=
=dJAO
-----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: Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/7/20 03:10, Rémy Maucherat wrote:
> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:

>
> All,
>
> Jakarta EE 5.0 does not appear to include support for SameSite
> cookies. Tomcat's CookieProcessor allows an administrator to set
> the SameSite cookie policy, but it's a blanket policy.
>
> So for example, if you want a JSESSIONID cookie to be "strict" but
> some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever,
> you will have to manually-build your "Set-Cookie" headers for your
> FOO cooki e.
>
> This is not terribly convenient.
>
> Unfortunately, *any* solution to this problem will be
> container-specific. The current Tomcat solution is of course a
> solution only for Tomcat, and only for versions which contain that
> SameSite support.
>
> I'm wondering if we can do better.
>
> Instead of a single "sameSiteCookies" setting which applies to
> *all* cookies, perhaps the CookieProcessor could have a different
> policy for specific cookies. Something like this:
>
> <CookieProcessor
> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
> sameSiteCookies="unset"> <SameSiteCookie cookieName="JSESSIONID"
> policy="strict" /> <SameSiteCookie cookieName="FOO" policy="lax"
> /> ... </CookieProcessor>
>
> In the above setup, the "sameSiteCookie" attribute of the
> CookieProcessor sets the default policy for the CookieProcessor.
> Then, each of the <SameSiteCookie> elements sets the policy for a
> specific cookie by name.
>
> This would allow applications to set their policies without having
> to construct their own Set-Cookie response headers, handle
> encoding, etc. and it would also inherit any other Tomcat-supplied
> cookie-related policies.
>
> Another option would be to provide a subclass of j.s.h.Cookie
> which includes a setSameSite(String) method. The CookieProcessor
> could check for instanceof EnhancedCookie (or whatever) and use
> that setting for each Cookie object. But that seems like less of a
> good idea -- except that it would be easier for refactoring tools
> to locate instances of the Tomcat-specific Cookie class and replace
> them with a future SameSite-supporting official Jakarta EE Cookie
> class.
>
> WDYT?
>
>
>> This is a big configuration and API change. Adding a new element
>> is significant, so maybe an expanded syntax could be added to the
>> attribute instead (ex: "unset,JSESSIONID=strict,FOO=lax"; or
>> maybe a more compact "unset;strict=JSESSIONID,FOO;lax=BAR"). It's
>> still a breaking change though.

I think it's *either* an API change *or* a configuration change, not
both, and it can be done in a backward compatible way.

Using a single "complex" configuration value makes it difficult or
impossible to write an XML schema for validation. Not critical, but
it's a consideration IMHO.

Nobody HAS to use e.g. a new Cookie class and/or new configuration. My
proposed configuration remains backward-compatible because the
sameSiteCookies attribute sets the default policy and it's only
overridden if you supply some cookie-specific configuration.

I don't think adding a new XML element as a child of SameSiteCookies
is a huge deal: it just requires a bit of Digester configuration and a
method to append custom configuration to SameSiteCookies. A quick
change to *CookieProcessor.generate() to check for custom settings
would be easy, tool. (I'd suggest that the code be refactored so that
the SameSiteCookies class returns the proper SameSite cookie attribute
(or null/blank) so that each CookieProperssor doesn't have to repeat
the logic.)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EhfEACgkQHPApP6U8
pFhXkxAAje++q65o9aq3L61hG+2y3B8yY+kFdiE+PwyvsVqbikHCSWNCVC3s8bpn
W56cYtajSGCItQvdrZfi76TowY2tnZHbzcJcquk6WMph/24nVMCekJ66ypQ3T1Hq
v6sn4sN8PZh8n3KoomeW2vy3oknbh0wX4IoTID333t02X15qdZbkngMmwouodH7d
aKF0yI2zBasz4J3XmCKWp/w7kfptp7Lf4TmxBcyEFJ1YKgQGMQCvQWUq6nBG9s6x
lt3fJJxNj44TtLQhu1k7LV/yesVO5V7IDQmvM7QfHo2Ny1M6eeMIMK2Yfelwa0uR
3yA5AmcVAVxh2d2PXKDJs1iy6u5hXZJtdXcPwE5qoTA9i4Au8SMDwJZPTmFlwPYc
NBsJWW4ahXFgcg+TyEZ1qSdk0HOsIrj21gLcsKZ6JMeu0mW2XZ1ekDS49+cBiXon
IUP7gfvMpGrp1eNbu6qVS6V8Odg1f11+iEC4w7gEhRER3KluHA9ujhMTR3lzR9ns
FcSmt16S6MNr1PK/5is2pNp4vFeGFVFUxvXxEt4SJGshF+WPrxDnWkCSs/hlRXR9
4bhUbXaBQuf827B4rONNepUf+fXoUQHkRmLcXFSF5Gx6rdtl1xm+OP9cPm+D0k6x
VAh5pLoXRtFv4NTMFyftBUVk0Kcm7EAsCwKbhDTEh8vsCKGFRTo=
=0n3F
-----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: Improving SameSite support

Rémy Maucherat
On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/7/20 03:10, Rémy Maucherat wrote:
> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:
>
> All,
>
> Jakarta EE 5.0 does not appear to include support for SameSite
> cookies. Tomcat's CookieProcessor allows an administrator to set
> the SameSite cookie policy, but it's a blanket policy.
>
> So for example, if you want a JSESSIONID cookie to be "strict" but
> some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever,
> you will have to manually-build your "Set-Cookie" headers for your
> FOO cooki e.
>
> This is not terribly convenient.
>
> Unfortunately, *any* solution to this problem will be
> container-specific. The current Tomcat solution is of course a
> solution only for Tomcat, and only for versions which contain that
> SameSite support.
>
> I'm wondering if we can do better.
>
> Instead of a single "sameSiteCookies" setting which applies to
> *all* cookies, perhaps the CookieProcessor could have a different
> policy for specific cookies. Something like this:
>
> <CookieProcessor
> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
> sameSiteCookies="unset"> <SameSiteCookie cookieName="JSESSIONID"
> policy="strict" /> <SameSiteCookie cookieName="FOO" policy="lax"
> /> ... </CookieProcessor>
>
> In the above setup, the "sameSiteCookie" attribute of the
> CookieProcessor sets the default policy for the CookieProcessor.
> Then, each of the <SameSiteCookie> elements sets the policy for a
> specific cookie by name.
>
> This would allow applications to set their policies without having
> to construct their own Set-Cookie response headers, handle
> encoding, etc. and it would also inherit any other Tomcat-supplied
> cookie-related policies.
>
> Another option would be to provide a subclass of j.s.h.Cookie
> which includes a setSameSite(String) method. The CookieProcessor
> could check for instanceof EnhancedCookie (or whatever) and use
> that setting for each Cookie object. But that seems like less of a
> good idea -- except that it would be easier for refactoring tools
> to locate instances of the Tomcat-specific Cookie class and replace
> them with a future SameSite-supporting official Jakarta EE Cookie
> class.
>
> WDYT?
>
>
>> This is a big configuration and API change. Adding a new element
>> is significant, so maybe an expanded syntax could be added to the
>> attribute instead (ex: "unset,JSESSIONID=strict,FOO=lax"; or
>> maybe a more compact "unset;strict=JSESSIONID,FOO;lax=BAR"). It's
>> still a breaking change though.

I think it's *either* an API change *or* a configuration change, not
both, and it can be done in a backward compatible way.

Using a single "complex" configuration value makes it difficult or
impossible to write an XML schema for validation. Not critical, but
it's a consideration IMHO.

Nobody HAS to use e.g. a new Cookie class and/or new configuration. My
proposed configuration remains backward-compatible because the
sameSiteCookies attribute sets the default policy and it's only
overridden if you supply some cookie-specific configuration.

I don't think adding a new XML element as a child of SameSiteCookies
is a huge deal: it just requires a bit of Digester configuration and a
method to append custom configuration to SameSiteCookies. A quick
change to *CookieProcessor.generate() to check for custom settings
would be easy, tool. (I'd suggest that the code be refactored so that
the SameSiteCookies class returns the proper SameSite cookie attribute
(or null/blank) so that each CookieProperssor doesn't have to repeat
the logic.)

If new elements are added, they need to correspond to an object structure (= there needs to be a SameSiteCookie object with fields "cookieName" and "policy" being added to a map in CookieProcessorBase). I am -1 for any custom digester behavior [the Connector element has this issue, and it's more or less unfixable now], instead the standard object create, set properties and set next rules have to be used.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EhfEACgkQHPApP6U8
pFhXkxAAje++q65o9aq3L61hG+2y3B8yY+kFdiE+PwyvsVqbikHCSWNCVC3s8bpn
W56cYtajSGCItQvdrZfi76TowY2tnZHbzcJcquk6WMph/24nVMCekJ66ypQ3T1Hq
v6sn4sN8PZh8n3KoomeW2vy3oknbh0wX4IoTID333t02X15qdZbkngMmwouodH7d
aKF0yI2zBasz4J3XmCKWp/w7kfptp7Lf4TmxBcyEFJ1YKgQGMQCvQWUq6nBG9s6x
lt3fJJxNj44TtLQhu1k7LV/yesVO5V7IDQmvM7QfHo2Ny1M6eeMIMK2Yfelwa0uR
3yA5AmcVAVxh2d2PXKDJs1iy6u5hXZJtdXcPwE5qoTA9i4Au8SMDwJZPTmFlwPYc
NBsJWW4ahXFgcg+TyEZ1qSdk0HOsIrj21gLcsKZ6JMeu0mW2XZ1ekDS49+cBiXon
IUP7gfvMpGrp1eNbu6qVS6V8Odg1f11+iEC4w7gEhRER3KluHA9ujhMTR3lzR9ns
FcSmt16S6MNr1PK/5is2pNp4vFeGFVFUxvXxEt4SJGshF+WPrxDnWkCSs/hlRXR9
4bhUbXaBQuf827B4rONNepUf+fXoUQHkRmLcXFSF5Gx6rdtl1xm+OP9cPm+D0k6x
VAh5pLoXRtFv4NTMFyftBUVk0Kcm7EAsCwKbhDTEh8vsCKGFRTo=
=0n3F
-----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: Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 04:16, Rémy Maucherat wrote:
> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:

>
> Rémy,
>
> On 7/7/20 03:10, Rémy Maucherat wrote:
>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>> <[hidden email]
>> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
>> All,
>
>> Jakarta EE 5.0 does not appear to include support for SameSite
>> cookies. Tomcat's CookieProcessor allows an administrator to set
>> the SameSite cookie policy, but it's a blanket policy.
>
>> So for example, if you want a JSESSIONID cookie to be "strict"
>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>> whatever, you will have to manually-build your "Set-Cookie"
>> headers for your FOO cooki e.
>
>> This is not terribly convenient.
>
>> Unfortunately, *any* solution to this problem will be
>> container-specific. The current Tomcat solution is of course a
>> solution only for Tomcat, and only for versions which contain
>> that SameSite support.
>
>> I'm wondering if we can do better.
>
>> Instead of a single "sameSiteCookies" setting which applies to
>> *all* cookies, perhaps the CookieProcessor could have a
>> different policy for specific cookies. Something like this:
>
>> <CookieProcessor
>> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>> sameSiteCookies="unset"> <SameSiteCookie cookieName="JSESSIONID"
>> policy="strict" /> <SameSiteCookie cookieName="FOO" policy="lax"
>> /> ... </CookieProcessor>
>
>> In the above setup, the "sameSiteCookie" attribute of the
>> CookieProcessor sets the default policy for the CookieProcessor.
>> Then, each of the <SameSiteCookie> elements sets the policy for
>> a specific cookie by name.
>
>> This would allow applications to set their policies without
>> having to construct their own Set-Cookie response headers,
>> handle encoding, etc. and it would also inherit any other
>> Tomcat-supplied cookie-related policies.
>
>> Another option would be to provide a subclass of j.s.h.Cookie
>> which includes a setSameSite(String) method. The CookieProcessor
>> could check for instanceof EnhancedCookie (or whatever) and use
>> that setting for each Cookie object. But that seems like less of
>> a good idea -- except that it would be easier for refactoring
>> tools to locate instances of the Tomcat-specific Cookie class and
>> replace them with a future SameSite-supporting official Jakarta
>> EE Cookie class.
>
>> WDYT?
>
>
>>> This is a big configuration and API change. Adding a new
>>> element is significant, so maybe an expanded syntax could be
>>> added to the attribute instead (ex:
>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking
>>> change though.
>
> I think it's *either* an API change *or* a configuration change,
> not both, and it can be done in a backward compatible way.
>
> Using a single "complex" configuration value makes it difficult or
> impossible to write an XML schema for validation. Not critical,
> but it's a consideration IMHO.
>
> Nobody HAS to use e.g. a new Cookie class and/or new configuration.
> My proposed configuration remains backward-compatible because the
> sameSiteCookies attribute sets the default policy and it's only
> overridden if you supply some cookie-specific configuration.
>
> I don't think adding a new XML element as a child of
> SameSiteCookies is a huge deal: it just requires a bit of Digester
> configuration and a method to append custom configuration to
> SameSiteCookies. A quick change to *CookieProcessor.generate() to
> check for custom settings would be easy, tool. (I'd suggest that
> the code be refactored so that the SameSiteCookies class returns
> the proper SameSite cookie attribute (or null/blank) so that each
> CookieProperssor doesn't have to repeat the logic.)
>
>
>> If new elements are added, they need to correspond to an object
>> structure (= there needs to be a SameSiteCookie object with
>> fields "cookieName" and "policy" being added to a map in
>> CookieProcessorBase).

The SameSiteCookies class already exists, and it can have a field and
method added (e.g. addCookie(String cookieName,String policy)). The
SameSiteCookies object can manage the policies and the CookieProcessor
classes can delegate the policy decisions to the SameSiteCookies object.

>> I am -1 for any custom digester behavior [the Connector element
>> has this issue, and it's more or less unfixable now], instead the
>> standard object create, set properties and set next rules have to
>> be used.

So this isn't okay with you?

digester.addCallMethod(".../Cookie", "addCookie", 2, [String,String]);
digester.addCallParam(".../Cookie", 0, "cookie");
digester.addCallParam(".../Cookie", 1, "policy");

??

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F1KoACgkQHPApP6U8
pFjLxBAAwQa2RIf7++TEeuX2JSBZBygVATpRJbBQH/s3nI8MsDbG1x8EL6Qcnx/7
cMDztQT63lfw4QPbhmumAnVa08rBczlLY2hDafTauDA9iIXgYcuGc+LeQeJHsPFK
Pc7yUpVEb+7P5nEi0x4ECvnpQ0QOsXj3JSQrfeMbuKE42NI7p0ZCusxJKTPez9C9
yveJU1j/Kzcl9Yr5khoGHhF1fqAuyA4zYikK9hIdVOEHFJ8jCpUIeej7SM3o942W
pf4X7FarNPHRBWAgYYK5+5/pBdb4whRRZeRlxvqntp1LhyBNXLk6vIuqaUTrAaGq
JWJlTVtozVD3DXPnSG7lIbx4u4unz8clJD27GuiiBdn+SGKG/RxeAcy+OksTjtLS
q3+IFbpt/eRfCi4akadINtsXagYZU8fT0fjFIgK9QJBJRPKgowWwEkjJaAAFJdws
OnSlB67Q7AM7zra065wt75L7z116hgYrPeacD8InaYbY67cpH8ziimryczIY5+Bh
5mNspX17I761WYsJT8aGaAnm/eigxez1z8qd5qgT4vz0df44uO6qOdIAWj/JN+W4
e04fJlUaHhYNdFG3bPHrDaiyeUY6ax52MYZiMmjE113rqxyrLEEFf1J1pfqP0SSE
w2kD7tboWzTSuAzR3caMW+2l2cTg3u+5Xd4KFMFIFcpCk7iGekM=
=4uZs
-----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: Improving SameSite support

Rémy Maucherat
On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 04:16, Rémy Maucherat wrote:
> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:
>
> Rémy,
>
> On 7/7/20 03:10, Rémy Maucherat wrote:
>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>> <[hidden email]
>> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
>> All,
>
>> Jakarta EE 5.0 does not appear to include support for SameSite
>> cookies. Tomcat's CookieProcessor allows an administrator to set
>> the SameSite cookie policy, but it's a blanket policy.
>
>> So for example, if you want a JSESSIONID cookie to be "strict"
>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>> whatever, you will have to manually-build your "Set-Cookie"
>> headers for your FOO cooki e.
>
>> This is not terribly convenient.
>
>> Unfortunately, *any* solution to this problem will be
>> container-specific. The current Tomcat solution is of course a
>> solution only for Tomcat, and only for versions which contain
>> that SameSite support.
>
>> I'm wondering if we can do better.
>
>> Instead of a single "sameSiteCookies" setting which applies to
>> *all* cookies, perhaps the CookieProcessor could have a
>> different policy for specific cookies. Something like this:
>
>> <CookieProcessor
>> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>> sameSiteCookies="unset"> <SameSiteCookie cookieName="JSESSIONID"
>> policy="strict" /> <SameSiteCookie cookieName="FOO" policy="lax"
>> /> ... </CookieProcessor>
>
>> In the above setup, the "sameSiteCookie" attribute of the
>> CookieProcessor sets the default policy for the CookieProcessor.
>> Then, each of the <SameSiteCookie> elements sets the policy for
>> a specific cookie by name.
>
>> This would allow applications to set their policies without
>> having to construct their own Set-Cookie response headers,
>> handle encoding, etc. and it would also inherit any other
>> Tomcat-supplied cookie-related policies.
>
>> Another option would be to provide a subclass of j.s.h.Cookie
>> which includes a setSameSite(String) method. The CookieProcessor
>> could check for instanceof EnhancedCookie (or whatever) and use
>> that setting for each Cookie object. But that seems like less of
>> a good idea -- except that it would be easier for refactoring
>> tools to locate instances of the Tomcat-specific Cookie class and
>> replace them with a future SameSite-supporting official Jakarta
>> EE Cookie class.
>
>> WDYT?
>
>
>>> This is a big configuration and API change. Adding a new
>>> element is significant, so maybe an expanded syntax could be
>>> added to the attribute instead (ex:
>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking
>>> change though.
>
> I think it's *either* an API change *or* a configuration change,
> not both, and it can be done in a backward compatible way.
>
> Using a single "complex" configuration value makes it difficult or
> impossible to write an XML schema for validation. Not critical,
> but it's a consideration IMHO.
>
> Nobody HAS to use e.g. a new Cookie class and/or new configuration.
> My proposed configuration remains backward-compatible because the
> sameSiteCookies attribute sets the default policy and it's only
> overridden if you supply some cookie-specific configuration.
>
> I don't think adding a new XML element as a child of
> SameSiteCookies is a huge deal: it just requires a bit of Digester
> configuration and a method to append custom configuration to
> SameSiteCookies. A quick change to *CookieProcessor.generate() to
> check for custom settings would be easy, tool. (I'd suggest that
> the code be refactored so that the SameSiteCookies class returns
> the proper SameSite cookie attribute (or null/blank) so that each
> CookieProperssor doesn't have to repeat the logic.)
>
>
>> If new elements are added, they need to correspond to an object
>> structure (= there needs to be a SameSiteCookie object with
>> fields "cookieName" and "policy" being added to a map in
>> CookieProcessorBase).

The SameSiteCookies class already exists, and it can have a field and
method added (e.g. addCookie(String cookieName,String policy)). The
SameSiteCookies object can manage the policies and the CookieProcessor
classes can delegate the policy decisions to the SameSiteCookies object.

>> I am -1 for any custom digester behavior [the Connector element
>> has this issue, and it's more or less unfixable now], instead the
>> standard object create, set properties and set next rules have to
>> be used.

So this isn't okay with you?

digester.addCallMethod(".../Cookie", "addCookie", 2, [String,String]);
digester.addCallParam(".../Cookie", 0, "cookie");
digester.addCallParam(".../Cookie", 1, "policy");

??

Clearly, no, with multiple elements, the digester rules added to ContextRuleSet would be something like (in addition to the unchanged ones for CookieProcessor):

        digester.addObjectCreate(prefix + "Context/CookieProcessor",
                                 "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
                                 "className");
        digester.addSetProperties(prefix + "Context/CookieProcessor");
        digester.addSetNext(prefix + "Context/CookieProcessor",
                            "setCookieProcessor",
                            "org.apache.tomcat.util.http.CookieProcessor");

        digester.addObjectCreate(prefix + "Context/CookieProcessor/SameSiteCookie",
                                 "org.apache.tomcat.util.http.SameSiteCookie",
                                 "className");
        digester.addSetProperties(prefix + "Context/CookieProcessor/SameSiteCookie");
        digester.addSetNext(prefix + "Context/CookieProcessor/SameSiteCookie",
                            "addSameSiteCookie",
                            "org.apache.tomcat.util.http.SameSiteCookie");

If the bean class is org.apache.tomcat.util.http.SameSiteCookie.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F1KoACgkQHPApP6U8
pFjLxBAAwQa2RIf7++TEeuX2JSBZBygVATpRJbBQH/s3nI8MsDbG1x8EL6Qcnx/7
cMDztQT63lfw4QPbhmumAnVa08rBczlLY2hDafTauDA9iIXgYcuGc+LeQeJHsPFK
Pc7yUpVEb+7P5nEi0x4ECvnpQ0QOsXj3JSQrfeMbuKE42NI7p0ZCusxJKTPez9C9
yveJU1j/Kzcl9Yr5khoGHhF1fqAuyA4zYikK9hIdVOEHFJ8jCpUIeej7SM3o942W
pf4X7FarNPHRBWAgYYK5+5/pBdb4whRRZeRlxvqntp1LhyBNXLk6vIuqaUTrAaGq
JWJlTVtozVD3DXPnSG7lIbx4u4unz8clJD27GuiiBdn+SGKG/RxeAcy+OksTjtLS
q3+IFbpt/eRfCi4akadINtsXagYZU8fT0fjFIgK9QJBJRPKgowWwEkjJaAAFJdws
OnSlB67Q7AM7zra065wt75L7z116hgYrPeacD8InaYbY67cpH8ziimryczIY5+Bh
5mNspX17I761WYsJT8aGaAnm/eigxez1z8qd5qgT4vz0df44uO6qOdIAWj/JN+W4
e04fJlUaHhYNdFG3bPHrDaiyeUY6ax52MYZiMmjE113rqxyrLEEFf1J1pfqP0SSE
w2kD7tboWzTSuAzR3caMW+2l2cTg3u+5Xd4KFMFIFcpCk7iGekM=
=4uZs
-----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: Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 10:20, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:

>
> Rémy,
>
> On 7/8/20 04:16, Rémy Maucherat wrote:
>> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
>> <[hidden email]
>> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
>> Rémy,
>
>> On 7/7/20 03:10, Rémy Maucherat wrote:
>>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>>> <[hidden email]
>>> <mailto:[hidden email]>
>>> <mailto:[hidden email]
> <mailto:[hidden email]>>
>>> <mailto:[hidden email]
> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>>> wrote:
>
>>> All,
>
>>> Jakarta EE 5.0 does not appear to include support for SameSite
>>> cookies. Tomcat's CookieProcessor allows an administrator to
>>> set the SameSite cookie policy, but it's a blanket policy.
>
>>> So for example, if you want a JSESSIONID cookie to be "strict"
>>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>>> whatever, you will have to manually-build your "Set-Cookie"
>>> headers for your FOO cooki e.
>
>>> This is not terribly convenient.
>
>>> Unfortunately, *any* solution to this problem will be
>>> container-specific. The current Tomcat solution is of course a
>>> solution only for Tomcat, and only for versions which contain
>>> that SameSite support.
>
>>> I'm wondering if we can do better.
>
>>> Instead of a single "sameSiteCookies" setting which applies to
>>> *all* cookies, perhaps the CookieProcessor could have a
>>> different policy for specific cookies. Something like this:
>
>>> <CookieProcessor
>>> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>>> sameSiteCookies="unset"> <SameSiteCookie
>>> cookieName="JSESSIONID" policy="strict" /> <SameSiteCookie
>>> cookieName="FOO" policy="lax" /> ... </CookieProcessor>
>
>>> In the above setup, the "sameSiteCookie" attribute of the
>>> CookieProcessor sets the default policy for the
>>> CookieProcessor. Then, each of the <SameSiteCookie> elements
>>> sets the policy for a specific cookie by name.
>
>>> This would allow applications to set their policies without
>>> having to construct their own Set-Cookie response headers,
>>> handle encoding, etc. and it would also inherit any other
>>> Tomcat-supplied cookie-related policies.
>
>>> Another option would be to provide a subclass of j.s.h.Cookie
>>> which includes a setSameSite(String) method. The
>>> CookieProcessor could check for instanceof EnhancedCookie (or
>>> whatever) and use that setting for each Cookie object. But that
>>> seems like less of a good idea -- except that it would be
>>> easier for refactoring tools to locate instances of the
>>> Tomcat-specific Cookie class and replace them with a future
>>> SameSite-supporting official Jakarta EE Cookie class.
>
>>> WDYT?
>
>
>>>> This is a big configuration and API change. Adding a new
>>>> element is significant, so maybe an expanded syntax could be
>>>> added to the attribute instead (ex:
>>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a
>>>> breaking change though.
>
>> I think it's *either* an API change *or* a configuration change,
>> not both, and it can be done in a backward compatible way.
>
>> Using a single "complex" configuration value makes it difficult
>> or impossible to write an XML schema for validation. Not
>> critical, but it's a consideration IMHO.
>
>> Nobody HAS to use e.g. a new Cookie class and/or new
>> configuration. My proposed configuration remains
>> backward-compatible because the sameSiteCookies attribute sets
>> the default policy and it's only overridden if you supply some
>> cookie-specific configuration.
>
>> I don't think adding a new XML element as a child of
>> SameSiteCookies is a huge deal: it just requires a bit of
>> Digester configuration and a method to append custom
>> configuration to SameSiteCookies. A quick change to
>> *CookieProcessor.generate() to check for custom settings would be
>> easy, tool. (I'd suggest that the code be refactored so that the
>> SameSiteCookies class returns the proper SameSite cookie
>> attribute (or null/blank) so that each CookieProperssor doesn't
>> have to repeat the logic.)
>
>
>>> If new elements are added, they need to correspond to an
>>> object structure (= there needs to be a SameSiteCookie object
>>> with fields "cookieName" and "policy" being added to a map in
>>> CookieProcessorBase).
>
> The SameSiteCookies class already exists, and it can have a field
> and method added (e.g. addCookie(String cookieName,String policy)).
> The SameSiteCookies object can manage the policies and the
> CookieProcessor classes can delegate the policy decisions to the
> SameSiteCookies object.
>
>>> I am -1 for any custom digester behavior [the Connector
>>> element has this issue, and it's more or less unfixable now],
>>> instead the standard object create, set properties and set next
>>> rules have to be used.
>
> So this isn't okay with you?
>
> digester.addCallMethod(".../Cookie", "addCookie", 2,
> [String,String]); digester.addCallParam(".../Cookie", 0,
> "cookie"); digester.addCallParam(".../Cookie", 1, "policy");
>
> ??
>
>
>> Clearly, no, with multiple elements, the digester rules added to
>> ContextRuleSet would be something like (in addition to the
>> unchanged ones for CookieProcessor):
>
> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>
>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
> "className"); digester.addSetProperties(prefix +
> "Context/CookieProcessor"); digester.addSetNext(prefix +
> "Context/CookieProcessor", "setCookieProcessor",
> "org.apache.tomcat.util.http.CookieProcessor");
>
> digester.addObjectCreate(prefix +
>> "Context/CookieProcessor/SameSiteCookie",
>
>> "org.apache.tomcat.util.http.SameSiteCookie",
> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
> digester.addSetNext(prefix +
>> "Context/CookieProcessor/SameSiteCookie",
> "addSameSiteCookie",
> "org.apache.tomcat.util.http.SameSiteCookie");
>
>> If the bean class is org.apache.tomcat.util.http.SameSiteCookie.

So you are okay with:

  digester.addSetProperties(prefix +
"Context/CookieProcessor/SameSiteCookie");


But not with:

  digester.addCallMethod(prefix +
"Context/CookieProcessor/SameSiteCookie/Cookie");

?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F150ACgkQHPApP6U8
pFiyDg//Q/GZr5CpEAtGSpLzDe78kYSDmBrZ3BCif+RBJvOUEarcpBskEDcjo3ux
uEYUQM4e+AniE3DzdL/3L7AYiaAZc5vwaKF1zE0OkisHJauYybRxPdhr0CwiKQ5R
/TkPNPc03nwzN/mYvSGUtVo/pyBkJ+2gX8bTFzkBrcha7F+6+lHmGzTpTgKYZVXQ
+DjmyiHvpSqmrvITYTo4NvNGKMckYzQ1hFXfzlW8fEsJsfxffAZqi3Sz1UikCs8F
/Tj12b814wNemtMR7nITWObCIGLYt8Xkv+Rv9kbglqsNSmGDv58f8CYGQjk4Mvk7
JEnLdSexEm979w+QNce3oibTVWdZjab2f1lLotTvcMIMenGHTefmpxlCQCjdMC0l
WT9EfAJUKC9bUMiysFUgce8DwYFBi9wmkKjBLtl0+Nynyt4GJIMKZlxAocgcEBs6
BqTa8G8xooC8/x5JSgWEu3r29Zn0zrHE4DJbH4egsoTVH3+U4FjsvMz/4lb/8hK+
RtRQxNJmPFutw1DEOSxbceahXVpjOXFs8KI09k+uz5OAY1C3alE3h9ig4PzjNzyS
N9fQ8XlCB+f9Agthjqbc3pNEDP2m2azuex6Wh4k72cyw6IGPreWO4rMTN4sTjGpg
ibsVK2ZBl7ssxVsgYfAk0r3FV6SAgP6LqhPAYqt1oDPDLcW5f5Y=
=Q7g+
-----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: Improving SameSite support

Rémy Maucherat
On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz <[hidden email]> wrote:
>> Clearly, no, with multiple elements, the digester rules added to
>> ContextRuleSet would be something like (in addition to the
>> unchanged ones for CookieProcessor):
>
> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>
>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
> "className"); digester.addSetProperties(prefix +
> "Context/CookieProcessor"); digester.addSetNext(prefix +
> "Context/CookieProcessor", "setCookieProcessor",
> "org.apache.tomcat.util.http.CookieProcessor");
>
> digester.addObjectCreate(prefix +
>> "Context/CookieProcessor/SameSiteCookie",
>
>> "org.apache.tomcat.util.http.SameSiteCookie",
> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
> digester.addSetNext(prefix +
>> "Context/CookieProcessor/SameSiteCookie",
> "addSameSiteCookie",
> "org.apache.tomcat.util.http.SameSiteCookie");
>
>> If the bean class is org.apache.tomcat.util.http.SameSiteCookie.

So you are okay with:

  digester.addSetProperties(prefix +
"Context/CookieProcessor/SameSiteCookie");


But not with:

  digester.addCallMethod(prefix +
"Context/CookieProcessor/SameSiteCookie/Cookie");

?

The digester works best with beans so I don't see what is so surprising about this.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F150ACgkQHPApP6U8
pFiyDg//Q/GZr5CpEAtGSpLzDe78kYSDmBrZ3BCif+RBJvOUEarcpBskEDcjo3ux
uEYUQM4e+AniE3DzdL/3L7AYiaAZc5vwaKF1zE0OkisHJauYybRxPdhr0CwiKQ5R
/TkPNPc03nwzN/mYvSGUtVo/pyBkJ+2gX8bTFzkBrcha7F+6+lHmGzTpTgKYZVXQ
+DjmyiHvpSqmrvITYTo4NvNGKMckYzQ1hFXfzlW8fEsJsfxffAZqi3Sz1UikCs8F
/Tj12b814wNemtMR7nITWObCIGLYt8Xkv+Rv9kbglqsNSmGDv58f8CYGQjk4Mvk7
JEnLdSexEm979w+QNce3oibTVWdZjab2f1lLotTvcMIMenGHTefmpxlCQCjdMC0l
WT9EfAJUKC9bUMiysFUgce8DwYFBi9wmkKjBLtl0+Nynyt4GJIMKZlxAocgcEBs6
BqTa8G8xooC8/x5JSgWEu3r29Zn0zrHE4DJbH4egsoTVH3+U4FjsvMz/4lb/8hK+
RtRQxNJmPFutw1DEOSxbceahXVpjOXFs8KI09k+uz5OAY1C3alE3h9ig4PzjNzyS
N9fQ8XlCB+f9Agthjqbc3pNEDP2m2azuex6Wh4k72cyw6IGPreWO4rMTN4sTjGpg
ibsVK2ZBl7ssxVsgYfAk0r3FV6SAgP6LqhPAYqt1oDPDLcW5f5Y=
=Q7g+
-----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: Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 10:35, Rémy Maucherat wrote:

> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>> Clearly, no, with multiple elements, the digester rules added
>>> to ContextRuleSet would be something like (in addition to the
>>> unchanged ones for CookieProcessor):
>>
>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>
>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>> "Context/CookieProcessor", "setCookieProcessor",
>> "org.apache.tomcat.util.http.CookieProcessor");
>>
>> digester.addObjectCreate(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>>
>>> "org.apache.tomcat.util.http.SameSiteCookie",
>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor/SameSiteCookie");
>> digester.addSetNext(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>> "addSameSiteCookie",
>> "org.apache.tomcat.util.http.SameSiteCookie");
>>
>>> If the bean class is
>>> org.apache.tomcat.util.http.SameSiteCookie.
>
> So you are okay with:
>
> digester.addSetProperties(prefix +
> "Context/CookieProcessor/SameSiteCookie");
>
>
> But not with:
>
> digester.addCallMethod(prefix +
> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
> ?
>
>
> The digester works best with beans so I don't see what is so
> surprising about this.

What's surprising is that you are -1 to what I see as an improvement
to Tomcat without much in the way of disruption. I think it's pretty
clean.

Would proposing an actual patch help, or will you still be -1 on
anything other than a complicated "sameSiteCookies" string value which
needs to be unpacked by Tomcat code rather than using standard XML
element/attribute syntax?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F4eMACgkQHPApP6U8
pFhhkxAAgQdr7vdbaO0qeWHPbKdh2hcy5NuKMOozOWaERHowTsx3yv9rHfiVKaXG
gti6mzcLIqXMPiMbqCE+fYpOCAfqJsAtjjg3zWs9Sh1vk7HOrOmZ7V2s5bbvjeqe
zCcrgdC+PKMO9Up/OWdwfAj8oARhtYFfTQfgoEiT61ElDYNnCU+swuDh9CZwJpv0
HzQ+U+kEEYpgZrawzuk4xCvOSk+HKNAcG5LDphYgLUGUNg3Eq7tlvzDSQ/PX1Hbd
VFHipCk4pDcRgvFq9GYK3b81QAlxcizFOW129+CPRSYINg1ztomv1Gqw+JXiwnG5
YCcd6LaBT0fn3SldtE/rWNZResK3qnQG0aeAFvdl1qzzWvOSMMzyuJB7XMxkRlTZ
lo3w7nJ9dJ4RdtjSshuBj6vrjFxqmAexbhy+e/aWmjKjjuEPl9oZx7jYbGKg79ER
Bn+6nkUEP7YxBMSg9LTqFJvzGw6PPplunn6MTef7PZYpj9qwJh5xg2AXGZqrndmD
XaowT4zNASfguq34BxmACWkqQrc6+3Wvdutafz7yvr0yxrvZz2+pmT6fJ9C6nBQO
4xyqxYRUa+Bt+4b2ppAzrVIJ+egk+6tbcUiqxMvbH1RV7GD+rwyEI5DRtv1RsTiw
lCI9Y4K3R2a1pEN/0nArQrkBAzEttlxTPoZ9eJyUxsuVXtLor6g=
=lUHF
-----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: Improving SameSite support

Rémy Maucherat
On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 10:35, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>> Clearly, no, with multiple elements, the digester rules added
>>> to ContextRuleSet would be something like (in addition to the
>>> unchanged ones for CookieProcessor):
>>
>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>
>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>> "Context/CookieProcessor", "setCookieProcessor",
>> "org.apache.tomcat.util.http.CookieProcessor");
>>
>> digester.addObjectCreate(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>>
>>> "org.apache.tomcat.util.http.SameSiteCookie",
>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor/SameSiteCookie");
>> digester.addSetNext(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>> "addSameSiteCookie",
>> "org.apache.tomcat.util.http.SameSiteCookie");
>>
>>> If the bean class is
>>> org.apache.tomcat.util.http.SameSiteCookie.
>
> So you are okay with:
>
> digester.addSetProperties(prefix +
> "Context/CookieProcessor/SameSiteCookie");
>
>
> But not with:
>
> digester.addCallMethod(prefix +
> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
> ?
>
>
> The digester works best with beans so I don't see what is so
> surprising about this.

What's surprising is that you are -1 to what I see as an improvement
to Tomcat without much in the way of disruption. I think it's pretty
clean.

Would proposing an actual patch help, or will you still be -1 on
anything other than a complicated "sameSiteCookies" string value which
needs to be unpacked by Tomcat code rather than using standard XML
element/attribute syntax?

The digester rules I posted add a new SameSiteCookie element. I only mentioned a complex sameSiteCookies attribute syntax once (I considered it would be better for API compatibility; the CookieProcessor API should not break in Tomcat 9 when things are backported, or the feature would be limited to Tomcat 10) but I didn't mention it again since you did not like it.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F4eMACgkQHPApP6U8
pFhhkxAAgQdr7vdbaO0qeWHPbKdh2hcy5NuKMOozOWaERHowTsx3yv9rHfiVKaXG
gti6mzcLIqXMPiMbqCE+fYpOCAfqJsAtjjg3zWs9Sh1vk7HOrOmZ7V2s5bbvjeqe
zCcrgdC+PKMO9Up/OWdwfAj8oARhtYFfTQfgoEiT61ElDYNnCU+swuDh9CZwJpv0
HzQ+U+kEEYpgZrawzuk4xCvOSk+HKNAcG5LDphYgLUGUNg3Eq7tlvzDSQ/PX1Hbd
VFHipCk4pDcRgvFq9GYK3b81QAlxcizFOW129+CPRSYINg1ztomv1Gqw+JXiwnG5
YCcd6LaBT0fn3SldtE/rWNZResK3qnQG0aeAFvdl1qzzWvOSMMzyuJB7XMxkRlTZ
lo3w7nJ9dJ4RdtjSshuBj6vrjFxqmAexbhy+e/aWmjKjjuEPl9oZx7jYbGKg79ER
Bn+6nkUEP7YxBMSg9LTqFJvzGw6PPplunn6MTef7PZYpj9qwJh5xg2AXGZqrndmD
XaowT4zNASfguq34BxmACWkqQrc6+3Wvdutafz7yvr0yxrvZz2+pmT6fJ9C6nBQO
4xyqxYRUa+Bt+4b2ppAzrVIJ+egk+6tbcUiqxMvbH1RV7GD+rwyEI5DRtv1RsTiw
lCI9Y4K3R2a1pEN/0nArQrkBAzEttlxTPoZ9eJyUxsuVXtLor6g=
=lUHF
-----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: Improving SameSite support

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 11:47, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:

>
> Rémy,
>
> On 7/8/20 10:35, Rémy Maucherat wrote:
>> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>> <[hidden email]
>> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
>>>> Clearly, no, with multiple elements, the digester rules
>>>> added to ContextRuleSet would be something like (in addition
>>>> to the unchanged ones for CookieProcessor):
>>>
>>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>>
>>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>>> "Context/CookieProcessor", "setCookieProcessor",
>>> "org.apache.tomcat.util.http.CookieProcessor");
>>>
>>> digester.addObjectCreate(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>>
>>>> "org.apache.tomcat.util.http.SameSiteCookie",
>>> "className"); digester.addSetProperties(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie");
>>> digester.addSetNext(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>> "addSameSiteCookie",
>>> "org.apache.tomcat.util.http.SameSiteCookie");
>>>
>>>> If the bean class is
>>>> org.apache.tomcat.util.http.SameSiteCookie.
>
>> So you are okay with:
>
>> digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
>
>
>> But not with:
>
>> digester.addCallMethod(prefix +
>> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
>> ?
>
>
>> The digester works best with beans so I don't see what is so
>> surprising about this.
>
> What's surprising is that you are -1 to what I see as an
> improvement to Tomcat without much in the way of disruption. I
> think it's pretty clean.
>
> Would proposing an actual patch help, or will you still be -1 on
> anything other than a complicated "sameSiteCookies" string value
> which needs to be unpacked by Tomcat code rather than using
> standard XML element/attribute syntax?
>
>
>> The digester rules I posted add a new SameSiteCookie element I
>> only>> mentioned a complex sameSiteCookies attribute syntax once
>> (I considered it would be better for API compatibility; the
>> CookieProcessor API should not break in Tomcat 9 when things are
>> backported, or the feature would be limited to Tomcat 10) but I
>> didn't mention it again since you did not like it.

I can't tell you if you are saying you'd be -1 to add that new
SameSiteCookie element (because it is "too big a change", or because
it requires "changes to digester configuration"), or that you are -1
to use digester.addCallMethod (because you don't like it), or that you
are -1 to really supporting any improvements to SameSite at all.

Can you clarify?

I won't waste my time if you are going to -1 anything I do, here.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8GFogACgkQHPApP6U8
pFg1UQ/+M9SU2f9YkLUnRU0f2MqdIwKFguLHFfFxZSnxoEOhIVJOmJbm5YrZlwIv
skzgJiPvX7wMWfq0wO8mc/ALjOAn/XhEE66sIWZe9bc9Hte0mrXHV8wmHZXhTW+O
LqLNGJgXH/m8Mxui27h2EfpRXYDEKEGLUU71j3NMOxd6xa0xfYv/MiBI3asMZpvQ
k688fWGa4EeoTj4yRtR+eIOYpcPFZlaT+uNFGPNr7HVMvSB0SAx/Ui732bMEXpRT
2CRaPSZ4TAFBhZLNXxfBodErGWA6QHQPgnPgB0oPbCM78R0zldVyXLMRpksZL/V7
Dx6cJE/Da7fISufomcMsdrpFmQ3LylXbKNTdbkzlDT9hdpgSn7kc4tDYJzwTt0NS
K2/fbi8gQOEg7VB6pRVeXxODhEovFizEKfuGhwFNyuw7q0cxK+w6W+zFdu+wgcj/
Epa/XDmtuKz5doGOnuwzpudf3For8rdVpdpmRUU7+1PiLX6xsj2cueY1ku7e45LL
ZR9cMGkW/sEU1oWw2HKM3fMqAuZEkFiNvYhua/KM6tVbqFXC49GeF+K+qe/zx2DK
W+xrPOnQ2A4viyLVAFbidPkxemdnp5VX+VXeXvgmCeRmsmWqvza73UJzf1Es4qg5
inLHbksUnsokixJHF2KwbsFFdubldl5HogNIpExmwwlb9Eg2fFI=
=j71t
-----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: Improving SameSite support

Rémy Maucherat
On Wed, Jul 8, 2020 at 8:55 PM Christopher Schultz <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 7/8/20 11:47, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz
> <[hidden email]
> <mailto:[hidden email]>>
wrote:
>
> Rémy,
>
> On 7/8/20 10:35, Rémy Maucherat wrote:
>> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>> <[hidden email]
>> <mailto:[hidden email]>
>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
>>>> Clearly, no, with multiple elements, the digester rules
>>>> added to ContextRuleSet would be something like (in addition
>>>> to the unchanged ones for CookieProcessor):
>>>
>>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>>
>>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>>> "Context/CookieProcessor", "setCookieProcessor",
>>> "org.apache.tomcat.util.http.CookieProcessor");
>>>
>>> digester.addObjectCreate(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>>
>>>> "org.apache.tomcat.util.http.SameSiteCookie",
>>> "className"); digester.addSetProperties(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie");
>>> digester.addSetNext(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>> "addSameSiteCookie",
>>> "org.apache.tomcat.util.http.SameSiteCookie");
>>>
>>>> If the bean class is
>>>> org.apache.tomcat.util.http.SameSiteCookie.
>
>> So you are okay with:
>
>> digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
>
>
>> But not with:
>
>> digester.addCallMethod(prefix +
>> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
>> ?
>
>
>> The digester works best with beans so I don't see what is so
>> surprising about this.
>
> What's surprising is that you are -1 to what I see as an
> improvement to Tomcat without much in the way of disruption. I
> think it's pretty clean.
>
> Would proposing an actual patch help, or will you still be -1 on
> anything other than a complicated "sameSiteCookies" string value
> which needs to be unpacked by Tomcat code rather than using
> standard XML element/attribute syntax?
>
>
>> The digester rules I posted add a new SameSiteCookie element I
>> only>> mentioned a complex sameSiteCookies attribute syntax once
>> (I considered it would be better for API compatibility; the
>> CookieProcessor API should not break in Tomcat 9 when things are
>> backported, or the feature would be limited to Tomcat 10) but I
>> didn't mention it again since you did not like it.

I can't tell you if you are saying you'd be -1 to add that new
SameSiteCookie element (because it is "too big a change", or because
it requires "changes to digester configuration"), or that you are -1
to use digester.addCallMethod (because you don't like it), or that you
are -1 to really supporting any improvements to SameSite at all.

Can you clarify?

Ok, another attempt then.

A SameSiteCookie element can be added using the following extra rules in ContextRuleSet:

        digester.addObjectCreate(prefix + "Context/CookieProcessor/SameSiteCookie",
                                 "org.apache.tomcat.util.http.SameSiteCookie",
                                 "className");
        digester.addSetProperties(prefix + "Context/CookieProcessor/SameSiteCookie");
        digester.addSetNext(prefix + "Context/CookieProcessor/SameSiteCookie",
                            "addSameSiteCookie",
                            "org.apache.tomcat.util.http.SameSiteCookie");

Other ways to add the element to server.xml don't work as well. It also keeps the embedded API consistent and storeconfig is likely the usual cut and paste.

Then I'm wondering about compatibility with the current CookieProcessor interface. If it's not compatible, the change would de facto be limited to Tomcat 10.


I won't waste my time if you are going to -1 anything I do, here.

I don't understand what was hard to understand in this case. Anyway, I had to pull quite a few ideas in the past personally, often due to a "it would break something" problem.

Rémy
 

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8GFogACgkQHPApP6U8
pFg1UQ/+M9SU2f9YkLUnRU0f2MqdIwKFguLHFfFxZSnxoEOhIVJOmJbm5YrZlwIv
skzgJiPvX7wMWfq0wO8mc/ALjOAn/XhEE66sIWZe9bc9Hte0mrXHV8wmHZXhTW+O
LqLNGJgXH/m8Mxui27h2EfpRXYDEKEGLUU71j3NMOxd6xa0xfYv/MiBI3asMZpvQ
k688fWGa4EeoTj4yRtR+eIOYpcPFZlaT+uNFGPNr7HVMvSB0SAx/Ui732bMEXpRT
2CRaPSZ4TAFBhZLNXxfBodErGWA6QHQPgnPgB0oPbCM78R0zldVyXLMRpksZL/V7
Dx6cJE/Da7fISufomcMsdrpFmQ3LylXbKNTdbkzlDT9hdpgSn7kc4tDYJzwTt0NS
K2/fbi8gQOEg7VB6pRVeXxODhEovFizEKfuGhwFNyuw7q0cxK+w6W+zFdu+wgcj/
Epa/XDmtuKz5doGOnuwzpudf3For8rdVpdpmRUU7+1PiLX6xsj2cueY1ku7e45LL
ZR9cMGkW/sEU1oWw2HKM3fMqAuZEkFiNvYhua/KM6tVbqFXC49GeF+K+qe/zx2DK
W+xrPOnQ2A4viyLVAFbidPkxemdnp5VX+VXeXvgmCeRmsmWqvza73UJzf1Es4qg5
inLHbksUnsokixJHF2KwbsFFdubldl5HogNIpExmwwlb9Eg2fFI=
=j71t
-----END PGP SIGNATURE-----

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