-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Lazar,
On 2/21/20 10:29, Lazar Kirchev wrote: > Yes, the SameSite attribute is still in a draft and this causes > the mess, at least partly.> And yes, I was thinking about something > like that - CookieProcessor.generateCookie(String userAgent, > Cookie) or CookieProcessor.generateCookie(Map<> requestHeaders, > Cookie). I absolutely > agree that this would be very hacky. And it might be dangerous as > CookieProcessor is an interface and there already might be custom > implementations. We can fix that with default implementations, for Java versions that support such thing (Java >= 1.8). > But can you think of another way of making the cookie generation > logic aware of the user agent header value? Not really. I have a preference for: CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) This is because User-Agent might not be the only header which is useful, here. For example, Google Chrome (amusingly enough) will be removing the User-Agent header[1] in favor of "client hints"[2]. So you might have to look at more than one header at a time, including possibly User-Agent. - -chris [1] https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in- chrome/ [2] https://wicg.github.io/ua-client-hints/ > On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Lazar, > > On 2/14/20 05:36, Lazar Kirchev wrote: >>>> Chris, >>>> >>>> Just FYI or in case someone else hits this problem. >>>> >>>> Actually I had to use the response wrapper approach for >>>> Tomcat 8.5.50 as well. As described by Chrome in >>>> https://www.chromium.org/updates/same-site/incompatible-clients, >>>> >>>> there are older browser versions which do not support the SameSite >>>> attribute at all and reject the cookies which contain it. >>>> Although Tomcat 8.5.42 and later provide the CookieProcessor >>>> configuration for the SameSite attribute, it is a problem if >>>> one wants to support older browser versions as well. > Wow, what a huge pain in the neck. I don't see anything in RFC > 6265 that says anything about rejecting cookies with unknown > attributes, but I also don't see anything prohibiting that > behavior, either. Than again, RFC 6265 doesn't mention the SameSite > attribute at all, so ... there is that. > > This is what you get when vendors try to implement standards > before they are standards. > >>>> Adding the SameSite attribute in order to support newest >>>> Chrome breaks the old ones as the configuration via the >>>> CookieProcessor does not allow for user agent sniffing. Even >>>> if you extend the existing CookieProcessor implementations or >>>> create your own, you cannot get the request headers in it so >>>> that you can check for the browser version. If one needs such >>>> flexibility, only the response wrapper helps. Do you think >>>> that it makes sense to provide a mechanism in the >>>> CookieProcessor to get access to the request headers in order >>>> to check the user agent? > Are you referring to CookieProcessor.generateCookie(Cookie)? So > the proposal would be to change that to > CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe > even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)? > > It seems super hacky to do it that way, but I'm not sure I see > another option for introducing SameSite in a compatible way. > > -chris >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5QEJgACgkQHPApP6U8 pFgC6w/7BzMCRdeR4Kldjigj6R48AUWcUorN0R1tQu4pxOT04DWPPkC+qXWoCtkT MNB3VgAuqjPnNLUDaGskvhU73p4lGqa2Z2scFKfS7CjTDs/cgwTusl+/bHqynK1P zxea0tU5DQvVUNbo5tvfWhwzoE/7/5lCcevkmBIwinktNr7+tOygIFvJl0vR7g5J diXmOlG0ratoGcbxr6qCzb/X3q7aUwn2U/m3yakX6HXcWg4tbOeVX969w5NU4i7c G+u5I+ayMqZt4DOU/5izuknsBUtvTEn36INoYaUmlK72KZofh9MOU56dSE/lyyPd snL493LHkgnCjpA8Se4GDHEV/TUqvn1/c0sSRzf6dMgwnE2w61VtJVzDstklWhWW 0S9GoTb+yi89QLcCPSJA2ZWiS2kbPMnEPqxgHTFwkhnqKpyjr9hw4h5O4Qr6fLYs bD8QihLWvyjoa4ImpIQZ3n+6556OEGYg6fUO/RKlx3cLB7nplsXUr0IxpE3XFW9T iV4ZaiZHtT+CtrDVqy2DO1kzj5GAxaoUWTXsDN4sqCwvJnAUId1rBpz0B1yZPPQh vPB3z6E1RmfOynY1ZWI+i3oJDd02ytsKsfnMaOYcYe8jE3WIsjvoCbzEQLr5nOQR YBSm40NqgJt3Obb2w/5IuFzgTSLyIpy8wIopYIUSmI1qhTDSEZQ= =mZj/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
