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

Reply via email to