You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rick Noel <RN...@westwoodone.com.INVALID> on 2024/03/15 17:49:51 UTC
RE: [EXT]Re: 404 for j_security_check
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
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
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
Rick Noel
Systems Programmer | Westwood One
RNoel@westwoodone.com
-----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 chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXT]Re: 404 for j_security_check
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rick,
On 3/19/24 12:58, Rick Noel wrote:
> 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.
Sorry for you, but glad it wasn't us :)
-chris
> -----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 chris@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 chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXT]Re: 404 for j_security_check
Posted by Rick Noel <RN...@westwoodone.com.INVALID>.
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
RNoel@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 chris@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 chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXT]Re: 404 for j_security_check
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org