On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz <
ch...@christopherschultz.net> 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: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to