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