There is a use-case when FROM authenticator does not remember original session inactive timeout value and (after successful authentication) the session inactive timeout remains at default 2 minutes value which is very low for a default web session. Example use case is as follows: 1. You access a protected resource for the first time. At this point the FORM authenticator forwards to login page and saves data from original request to session note Constants.FORM_REQUEST_NOTE including sesion original inactive timeout value and resets temporarly the session inactive timeout to 2 minutes (default value) 2. You refresh page from browser inside 2 minutes timeframe. At this point the FORM authenticator forwards again to login page and saves again data from this request. AT THIS POINT: you loose the original inactive timeout, because at step 1 the session inactive timeout was set to 2 minutes. In order to correct this use case we propose to change the code from class org.apache.catalina.authenticator.FormAuthenticator in tomcat-catalina as follows: line 719 (as of release 10.1.13) which now has the following contents: if (session instanceof HttpSession && ((HttpSession) session).isNew()) { int originalMaxInactiveInterval = session.getMaxInactiveInterval(); if (originalMaxInactiveInterval > getAuthenticationSessionTimeout()) { saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); } } change it to the following contents: final SavedRequest oldSaved = (SavedRequest) session.getNote(Constants.FORM_REQUEST_NOTE); if (session instanceof HttpSession) { final HttpSession httpSession = (HttpSession) session; if (httpSession.isNew()) { final int originalMaxInactiveInterval = session.getMaxInactiveInterval(); if (originalMaxInactiveInterval > authenticationSessionTimeout) { saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); session.setMaxInactiveInterval(authenticationSessionTimeout); } } else if ((oldSaved != null) && (oldSaved.getOriginalMaxInactiveInterval() > 0)) { saved.setOriginalMaxInactiveInterval(oldSaved.getOriginalMaxInactiveInterval()); } } PS: the problem seems to exist also in current release of Tomcat 11.x, Tomcat 8.5.x, Tomcat 9.0.x Best regards.
Hi All, We are also facing same issue, it is same as mail sent to mailing list "users@tomcat.apache.org" with subject "Tomcat 9.0.75 ignoring session timeout configured in tomcat conf web.xml" Details Below ============== Tomcat Version : 9.0.75 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.75 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. ========================== <session-config> <session-timeout>30</session-timeout> // 30 minutes </session-config> ========================= Verified the Tomcat source code - FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) - As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value - This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation - Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. ------------------------------------------------------------------------------------------------------------------------------ Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the authenticationSessionTimeout attribute of the FORM authenticator. (markt) ------------------------------------------------------------------------------------------------------------------------- Could you please fix this bug and help. Thanks Channa
Hi Channa, Yes it is the same issue and the proposed code correction (or any equivalent form) actually solves your problem too. The proposed code correction actually preserves the added functionality documented as "Harden the FORM authentication process against DoS attacks" and solves the problem of honoring the session timeout configuration from web.xml. I am also waiting that proposed code correction (or any equivalent form) to reach all maintained branches of Tomcat (8.5.x, 9.0.x, 10.1.x and main = 11.x) that have this problem. Thanks, Mircea
Hi Tomcat Team, Any update on solution or future release which resolves this issue. Thanks Channa
Fixed in: - 11.0.x for 11.0.0-M14 onwards - 10.1.x for 10.1.16 onwards - 9.0.x for 9.0.83 onwards - 8.5.x for 8.5.96 onwards Thanks for the proposed fix. I just made a few minor adjustments.
Thank you for the fix. Would like to know, When Tomcat version 9.0.83 is available ? Thanks Channa
Hi Team, We verified on Tomcat 9.0.83, but issue not resolved, session getting timeout after 2 minutes. Anyone verified and confirmed the fix. Could you please confirm. Thanks Channa
Dear Channa, I have just tested with tomcat 10.1.16 that contains the fix and after passing form authentication the session timeout reverts to default 30 minutes as calculated from application web.xml or default value. Of course that during display of login page the session timeout is changed to 2 minutes because this is the intent and should be. Anyway this parameter can be changed by inserting a valve for form authenticator with parameter authenticationSessionTimeout set to your new preferred value. I am very confident that 9.x branch contains correction equivalent to 10.1.x branch. Maybe you can elaborate your use case scenario. Thanks, Mircea
This issue is resolved. Please take any follow-up questions to the users mailing lists and provide *detailed* steps to recreate any issues still observed.
Hi Mark and Mircea, Issue still occurring with Tomcat 9.0.83. Could someone cross verify and confirm the fix please. Thanks Channa
Please DO NOT re-open this issue. If you think you still see this issue in a version that is meant to be fixed, follow the instructions in comment #8.