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