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