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