Chris, Thanks for the help, I agree with all your statements.
I now see the JSESSIONID cookies. I found a bug in my code. My issue was nothing to do with Tomcat behavior. Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Sunday, March 17, 2024 10:57 AM To: users@tomcat.apache.org Subject: Re: [EXT]Re: 404 for j_security_check [You don't often get email from ch...@christopherschultz.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Rick, On 3/15/24 13:49, Rick Noel wrote: > > I really only want auth once > > All hits to jsp pages after a successful login do not trigger the Auth > process again. > > But hits to java action class servlets do trigger the Auth process > > Its like session data is being lost for some pages but not for others Can you watch the HTTP headers for your interaction to see what's happening? The browser should be sending JSESSIONID cookies with each request. If the server isn't sending any Set-Cookie header, the browser should leave things as they are. Please note that Tomcat will send Set-Cookie when a session is created (by default, every JSP will create a session IIRC if you declare it to use sessions), plus Tomcat will rotate the session identifier as part of the authentication process. If you have code on the client that is storing the session and using it later, if your session id is being updated during authentication you need to make sure it gets updated everywhere the client is using it. > I was thinking maybe this is reason...... > > The Expires header specifies when content will expire, or how long content is > "fresh." > After this time, the Portal Server will always check back with the remote > server to see if the content has changed. > Most Web servers allow setting an absolute time to expire, a time > based on the last time that the client saw the object (last access time), or > a time based on the last time the document changed on your server (last > modification time). > > In JSP, we can set caching to forever using the Expires header like > so......... > > response.setDateHeader("Expires",Long.MAX_VALUE) > > BUT I do not want to change my application code, I just want to tell > Tomcat 10 to stop Expiring cache so that session log in data is not > lost No, the cache here refers to the client's resource (e.g. page, image, etc.) cache. It has nothing to do with what's happening on the server. > My main question is.... > I want to know how to configure Tomcat 10 to not loose session data > that tells the user has successfully logged in Are you properly encoding your URLs in your page like with HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking it probably won't matter, but it's best practice to always do that to ensure your URLs are generated properly. -chris > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Friday, March 15, 2024 12:19 PM > To: users@tomcat.apache.org > Subject: [EXT]Re: 404 for j_security_check > > [You don't often get email from ch...@christopherschultz.net. Learn > why this is important at https://aka.ms/LearnAboutSenderIdentification > ] > > Rick, > > On 3/14/24 15:37, Rick Noel wrote: >> After moving from tomcat 9 to tomcat 10 after a user successfully >> logs in and then hits a restricted page, the login page is hit again >> but on this second login hit I get 404 page not found > This is actually expected, since j_security_check is only supposed to be used > when the container (Tomcat) interrupts a user workflow to request > authentication. > >> How do I set the correct path in my login jsp so that >> j_security_check is found? >> >> BTW I actually am wondering why a successful logged on user would >> even be sent to the log in page again? > That's more of a question for your application than anything else. > >> My login page is -> /membership/login.jsp >> >> Here is how I set the path to j_security_check in above login.jsp >> >> <form name="login_form" action='j_security_check' method='POST'> >> >> My restricted web.xml snippet............ > > Are you doing what I call a "direct login" where you have a "login page" > that most users hit first. Like from example.com/app/ where there is no > initial request for a protected resource? Or are your users always (1) > requesting a protected resource then (2) Tomcat requests authentication then > (3) the user is forwarded to the resource originally requested in (1)? > >> <security-constraint> >> <web-resource-collection> >> <web-resource-name>External</web-resource-name> >> <url-pattern>/external/*</url-pattern> >> </web-resource-collection> >> <auth-constraint> >> <role-name>radiovoodoo</role-name> >> </auth-constraint> >> <user-data-constraint> >> <transport-guarantee>NONE</transport-guarantee> >> </user-data-constraint> >> </security-constraint> >> <security-constraint> >> <web-resource-collection> >> <web-resource-name>Auth</web-resource-name> >> <url-pattern>/auth/*</url-pattern> >> </web-resource-collection> >> <auth-constraint> >> <role-name>radiovoodoo</role-name> >> </auth-constraint> >> <user-data-constraint> >> <transport-guarantee>NONE</transport-guarantee> >> </user-data-constraint> >> </security-constraint> >> <login-config> >> <auth-method>FORM</auth-method> >> <form-login-config> >> <form-login-page>/membership/login.jsp</form-login-page> >> <form-error-page>/membership/error.jsp</form-error-page> >> </form-login-config> >> </login-config> > > Those <transport-guarantee>NONE</transport-guarantee> lines look weird to me. > Why are you explicitly specifying those? What part of your configuration > actually requests authentication and authorization? > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you know the sender and you are sure the > content is safe. Please report the message using the Report Message feature > in your email client if you believe the email is suspicious. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org