Hi,

Thanks for the reply.

We tried the settings on multiple machines. And found that the same
configuration machines gave different results.
We are getting multiple jsessionid cookies being created. In our
application, we have a multi tenant application.
For each tenant we have an nginx running calling the application url.
URL being hit on browser is like
*<TENANAT>.myapp.com <http://myapp.com>*
We are able to see 2 JSESSIONID cookies being generated for this call on
some machines.
1. domain: /myapp  which is having secure flag.
2. domain: /myapp/ which is NOT having secure flag.

Strangely, in most machines, we are finding the second cookie being
generated but the first cookie not generated.
Only when we saw on one of the machines, the first cookie, we found that
the secure jsessionid cookie being generated on that particular environment.

The environment having 2 cookies and the one with one cookie are identical.
Can you please help me fix the creation of the second cookie and also how
to ensure that the first cookie is generated in all environments?


On Tue, Jan 5, 2021 at 1:24 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mark,
>
> On 1/4/21 03:17, Mark Thomas wrote:
> > On 04/01/2021 06:02, Amit Khosla wrote:
> >> Hi,
> >>
> >> We are still facing this issue. Can someone please help us?
> >
> > In a clean 8.5.x install, session cookies are only marked as secure if
> > the request that triggered the session creation is made over a secure
> > channel (typically HTTPS).
> >
> > If you amend the session configuration in $CATALINA_BASE/conf/web.xml
> from:
> >
> > <session-config>
> >      <session-timeout>30</session-timeout>
> > </session-config>
> >
> > to
> >
> > <session-config>
> >      <session-timeout>30</session-timeout>
> >      <cookie-config>
> >          <secure>true</secure>
> >      </cookie-config>
> > </session-config>
> >
> > then session cookies will be generated with the secure flag whether or
> > not the request that triggered the the session creation was made over a
> > secure channel.
> >
> > Reviewing the thread:
> >
> > Are you sure you are amending the correct web.xml file? One way to check
> > this is to make a deliberate error in the file and confirm that this
> > error is reported when Tomcat starts.
> >
> > Note that you can only use <session-config> once in a web.xml file. If
> > the web.xml file already contains a <session-config> element you must
> > add to that existing element.
> >
> > Configuration in the application's web.xml file will override the global
> > web.xml file. Make sure that the application's web.xml either does not
> > specify a value for secure or specifies true.
> >
> > If you still have issues:
> > - start with a clean Tomcat 8.5.x install
> > - confirm that
> >    http://localhost:8080/examples/servlets/servlet/SessionExample
> >    generates a set-cookie header without the secure attribute
> > - stop Tomcat
> > - close the browser
> > - amend conf/web.xml as above
> > - start Tomcat
> > - confirm that
> >    http://localhost:8080/examples/servlets/servlet/SessionExample
> >    generates a set-cookie header with the secure attribute
> > - retest with your application
> >
> > You must close the browser between each request you expect to generate a
> > session cookie to prevent any existing session from being used.
>
> You may be able to avoid this with either of:
>
> 1. "Private" browsing mode: use a new "private" tab/window each time
>
> 2. Under developer tools / Storage (you may have to poke around for
> this), you should be able to see the cookies for the host and, if
> appropriate, delete them.
>
> > If this test fails then you'll need to check the application source
> > code. It is possible that the application is overriding your attempts to
> > make the session cookie secure.
>
> +1
>
> Other possibilities include a reverse proxy where the client is using
> HTTPS to communicate with the proxy, but HTTPS is not being used between
> the proxy and the Tomcat server.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Thanks & Regards
Amit Khosla

Reply via email to