-----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
