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. 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? Kind regards, Lazar On Tue, Feb 4, 2020 at 5:54 PM Lazar Kirchev <lazar.kirc...@gmail.com> wrote: > Thanks a lot Chris! I wish I could just get away from Tomcat 7 and upgrade > to 8.5, but I can't. Yes, the response wrapping will do. > > Lazar > > On Mon, Feb 3, 2020 at 4:30 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Lazar, >> >> On 2/3/20 5:42 AM, Lazar Kirchev wrote: >> > Chris, >> > >> > With "having control on the server but not on the application" I >> > meant that I could make changes on the server, but I have no >> > control to make modification on the application code. My concern >> > with the changed Chrome behavior regarding the same site cookie >> > attribute (https://www.chromestatus.com/feature/5088147346030592) >> > is that assuming "lax" as default value of the same site attribute >> > would break some specific authentication scenarios. Here I am >> > concerned particularly with the same site attribute of the >> > JSESSIONID cookie. >> >> Do you need your JSESSIONIDs to be sent to domains other than the one >> where the application actually lives? The whole same-site thing exists >> to fix some corner-cases in cookie theft. A "typical" application >> should not need any intervention, I think. >> >> > In a valve I can modify a header when the valve is invoked and >> > before it calls the next valve in the chain, but at that time the >> > JSESSIONID cookie may not be issued yet. >> >> There are other options. >> >> > And when the control comes back to the valve on the way back it may >> > be too late to change the header value. >> >> There are other options. >> >> > In Tomcat 8 and above the same site attribute can be specified as >> > a configuration to the CookieProcessor implementation. Is it >> > possible to achieve this reliably in Tomcat 7? >> >> Not with Tomcat's code. This does not appear to have been back-ported. >> >> I think you have two options: >> >> 1. Upgrade to Tomcat 8.5 (it's less painful than you might think) >> >> 2. Write a Valve and install it in the application: >> - For each request >> a. Wrap the response object in a wrapper class you write >> b. Dispatch the request as usual, using your response wrapper >> - Your wrapper class should: >> a. Extend o.a.c.connector.Response >> b. Override generateCookieString(Cookie) >> c. Call the superclass method, mutate as necessary >> d. Return the massaged cookie string >> >> I'm not sure which of those you consider riskier for your environment. >> You are cutting it a little close (chrome 80 is scheduled to be stable >> tomorrow). >> >> - -chris >> >> > Lazar, >> > >> > On 1/30/20 12:25 PM, Lazar Kirchev wrote: >> >>>> The problem is that I cannot make it from within the >> >>>> application. I have no control on the application, only on >> >>>> the server, so I have to be able to set the cookie either in >> >>>> a server configuration or in a component which will reside in >> >>>> the server. >> > >> > It's not clear to me what you mean by "server". Usually, the >> > application runs on the server, so if you only have control of the >> > server... you have control of the application. >> > >> >>>> I am concerned particularly with the SameSite attribute of >> >>>> the JSESSIONID cookie because of the new behavior of Chrome >> >>>> 80 - https://www.chromestatus.com/feature/5088147346030592 >> > >> > What is your specific concern? >> > >> >>>> I was considering to have a valve which modifies the >> >>>> Set-Cookie header. But I if the application flushes the >> >>>> output stream the headers will be written to the socket and >> >>>> the valve will not have the chance to modify the cookie. >> > You can use a <Valve> which can intercept the calls to >> > setHeader(), etc. to correct the header value. >> > >> > Which cookie are you trying to modify? >> > >> > -chris >> > >> >>>> On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < >> >>>> ch...@christopherschultz.net> wrote: >> >>>> >> >>>> John, >> >>>> >> >>>> On 1/27/20 9:37 AM, John Dale wrote: >> >>>>>>> Over the years I found it more productive to manage my >> >>>>>>> own headers for the most part. >> >>>>>>> >> >>>>>>> The key for us has been keeping the code clean and >> >>>>>>> manageable. >> >>>> >> >>>> +1 >> >>>> >> >>>> But there isn't any reason not to use Tomcat's header >> >>>> parsing. If you have anything that could be considered odd, >> >>>> you should encode it in a safe way that doesn't require that >> >>>> you play other games with the cookie value. >> >>>> >> >>>> For example, base64 encoding a cookie value should make it >> >>>> header-safe, as long as you make sure to use a base64 encoder >> >>>> that doesn't add newlines. >> >>>> >> >>>> -chris >> >>>> >> >>>>>>> On 1/27/20, Lazar Kirchev <lazar.kirc...@gmail.com> >> >>>>>>> wrote: >> >>>>>>>> Hello, >> >>>>>>>> >> >>>>>>>> In Tomcat >= 8 there is the CookieProcessor in which >> >>>>>>>> cookie configurations could be made, including for >> >>>>>>>> SameSite cookie. Is there any way to configure this >> >>>>>>>> in Tomcat 7? Or the only way is to configure it >> >>>>>>>> manually in code? >> >>>>>>>> >> >>>>>>>> Kind regards, Lazar >> >>>>>>>> >> >>>>>>> >> >>>>>>> ---------------------------------------------------------------- >> - --- >> >> >> >> >> >>>>>>> >> - --------------------------------------------------------------------- >> >> 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/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44LokACgkQHPApP6U8 >> pFjIyQ/9GGUXZZX//bAStwgisWYLecElE61d01I7+hRwWMS1NvbBPSZ+rQ7EE1KV >> wojDvdIjcSk5krz4jKcA3OXSZv/lAmpACCSydKs6V07FJkV8jBn4Hb1+8sA5/RmA >> /qfVXoN+uWDelcxazEtNZzje0I5tGyQ1Cfv2qCKly2uKmIlsy2Fs5cDqLF8phP2Z >> GzzgeV4bHW+uwTC78z6sTUdclmGDsCF7sk1/Jmttv8XkvEAHhbXPcPK0rwxcBr5s >> R8PLUzJ+9YDfj2Q7KAa6uSYKx3s1KvH7XlIc9xnVsOE45LGhU9a6jMAetOmF3mNT >> GGos+LzcNiYNEtUWGG9kbQZHS0sogjQbHNhTwCZvlNx+N3oaNeGtGlfX2SgIbA2I >> NacG/31UNEu6uGhC/rh0sP0kA3eadQw/hy9ayeu6BdwpsSVgCMb45T0MpuW9FCbV >> CSwtLUX3I3cGHkst+w9zqFMhEktuBazg9lC2juGOTxK+8oTjTlk4bUfb2clDbYmW >> s0I8KK/ZfK5Vf1hgbZHIL/JfotFh79ROYNtUEEzaFlCMzxtdVqYTfb1A97ekboBl >> nsOgPVcpAPUF0loUBykYDOLh1xQ764MjrlEzcgDoQOUfvO/B99NuWI49S53iti/a >> HKIScIjRykysE2M7xOJSCZCPsHz8X8jfzE3QvVXkG1rezx+bw/4= >> =Dk7I >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
