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