-----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 > <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
