-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rémy,
On 7/8/20 10:20, Rémy Maucherat wrote: > On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz > <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> wrote: > > 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> >> <mailto: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>> >>> <mailto: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. So you are okay with: digester.addSetProperties(prefix + "Context/CookieProcessor/SameSiteCookie"); But not with: digester.addCallMethod(prefix + "Context/CookieProcessor/SameSiteCookie/Cookie"); ? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F150ACgkQHPApP6U8 pFiyDg//Q/GZr5CpEAtGSpLzDe78kYSDmBrZ3BCif+RBJvOUEarcpBskEDcjo3ux uEYUQM4e+AniE3DzdL/3L7AYiaAZc5vwaKF1zE0OkisHJauYybRxPdhr0CwiKQ5R /TkPNPc03nwzN/mYvSGUtVo/pyBkJ+2gX8bTFzkBrcha7F+6+lHmGzTpTgKYZVXQ +DjmyiHvpSqmrvITYTo4NvNGKMckYzQ1hFXfzlW8fEsJsfxffAZqi3Sz1UikCs8F /Tj12b814wNemtMR7nITWObCIGLYt8Xkv+Rv9kbglqsNSmGDv58f8CYGQjk4Mvk7 JEnLdSexEm979w+QNce3oibTVWdZjab2f1lLotTvcMIMenGHTefmpxlCQCjdMC0l WT9EfAJUKC9bUMiysFUgce8DwYFBi9wmkKjBLtl0+Nynyt4GJIMKZlxAocgcEBs6 BqTa8G8xooC8/x5JSgWEu3r29Zn0zrHE4DJbH4egsoTVH3+U4FjsvMz/4lb/8hK+ RtRQxNJmPFutw1DEOSxbceahXVpjOXFs8KI09k+uz5OAY1C3alE3h9ig4PzjNzyS N9fQ8XlCB+f9Agthjqbc3pNEDP2m2azuex6Wh4k72cyw6IGPreWO4rMTN4sTjGpg ibsVK2ZBl7ssxVsgYfAk0r3FV6SAgP6LqhPAYqt1oDPDLcW5f5Y= =Q7g+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
