Chris, CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will work perfectly for me and I guess for anyone who needs to check the client version.
Kind regards, Lazar On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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/ > <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 > >
