Chris, Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should be able to work both on Java 7 and Java 8, interface default methods can't be used. So would you prefer to have a second CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) in addition to the existing CookieProcessor.generateCookie(Cookie), and provide a no-op implementation in the CookieProcessorBase class, or to change the signature of the existing method instead? I myself prefer the first option, with adding a second method.
Lazar On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Lazar, > > On 2/24/20 02:05, Lazar Kirchev wrote: > > Chris, > > > > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will > > work perfectly for me and I guess for anyone who needs to check the > > client version. > > Want to prepare a PR? > > - -chris > > > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > 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-i > n- > > > > > chrome/ > > <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 > >>>>> > >>>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> > >> > 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/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5T6WwACgkQHPApP6U8 > pFhGHxAAwiVqrNm6k4LjfFedovPEVPADUqGe1cT9UIB1seFUhPJ2u1REgVhOoAsq > EuIxnn69nRpqqtp31petFk7D1XMw9HQHgr6dXBJILL+fPxqZxvavDeM+jqXL/D4O > +UTzz85EXMl0A/HVkIYR9tb0kW3lgLEvdyYeWQB+0sz3pzdyIxW6ZtKOfRFOwjff > 8ptTKz6XJN3gWyZ5dOwsJ+umPQeqOLoxn9bmlKJnXFZHsfzVhBUy2T0b0NmZguyX > hRNfnNDF7cAvQjWPzM9CgqyZlTtcVJGZ2ugwkK7C1PGQXXnMrCLDm6rKLOBYIsXW > RHBedq0b+T1QDnM9imYjySNTr5mLZg5sHeeQ8RhWgxMBW4wfvTCqbHm4RZurOeXj > ZgMfj8r7zcy2becdo5dCC73e7r8B0F0MumcbqN02y1z6eVysKut4UJFQFB7L408H > PMgclJVVNc+bQeRI0Vs8IYA/FP6gm7Cow/Tk6OeAdOx+JhJuWFS/DEwTAahGD2pS > bOGUHmOq/HlfofjbSjAiBPrw+18WBPaFscw366s3W6NhETJVsjEF+DShi8SQ/+Ps > cOHgfmBn0yHbkKiBDvqe3oqqPBtvh0rP4fIJ8wfVS2BIBEAAj8+XTNoiRciZa/kM > afSP2HtGdN/4hxW6lc31kePN82kkO9cjm6IEfck0dzae5/mmlDs= > =KXMS > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
