Re: [EXT]Re: 404 for j_security_check

[Christopher Schultz]

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



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




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE 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.

TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Justin Y]

Hi Everyone --

  I've spent a few hours scratching my head and then diving into the 
source code of 10.1.19 to figure out what's going on.


  I'm using the /TLSCertificateReloadListener/ 
 
to reload files that will be (eventually) managed by Let's Encrypt.


  Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are used 
forever, causing the trigger to reoccur again and again.


  The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null out 
the "sslContext" on line 102 of AbstractJsseEndpoint.


  From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


  From my limited knowledge, it appears the files will never be loaded 
unless a new instance of SSLContext is created.


  I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and key 
files (no CA).


  I have tried writing my own /TLSCertificateReloadListener/ 
 
implementation but have found no clear way to null the SSLContext of the 
(determined expired) SSLHostConfigCertificate objects to allow a reload.


  I appreciate any suggestions!

-- Justin

--
Justin Yunke