tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <d...@cornell.edu>
Subject Re: j_security_check redirect after login
Date Thu, 08 Nov 2007 19:45:23 GMT
>
>
>3. It is unclear what happens in the event when a user requests the
>form-
>   login-page directly instead of going through a container-managed 
>   resource.
>
>   How does j_security_check know where to redirect the user once he has
>
>   authenticated successfully?
>  
>

That's not allowed.  At minimum it generates an exception in the logs.  
I don't remember at the moment what it does on the client side -- 
possibly return some sort of 4xx error.  I'm sure a quick search of the 
archives will bring back a lot of messages though.

--David


Andrew R Feller wrote:

>Thank you Chuck, Matthias; I appreciate the direction.  The reasons why
>I ask are:
>
>1. There were no apparent connections between requesting a
>container-managed 
>   resource, logging in via the form-login-page, and receiving the 
>   originally requested container-managed resource.
>
>2. Little documentation on j_security_check from vendors; just assumes 
>   people know it is part of the servlet specification.
>
>3. It is unclear what happens in the event when a user requests the
>form-
>   login-page directly instead of going through a container-managed 
>   resource.
>
>   How does j_security_check know where to redirect the user once he has
>
>   authenticated successfully?
>
>4. I appreciate understanding exactly what is going on in a system.
>
>Andrew R Feller, Analyst
>Subversion Administrator
>University Information Systems
>Louisiana State University
>afelle1@lsu.edu
>(office) 225.578.3737
>
>-----Original Message-----
>From: Reich, Matthias [mailto:matthias.reich@siemens.com] 
>Sent: Thursday, November 08, 2007 12:08 PM
>To: Tomcat Users List
>Subject: RE: j_security_check redirect after login
>
>
> You should also have a look at
>/org/apache/catalina/authenticator/FormAuthenticator.java
> 
>In this class you can find the details about how requests are saved and
>restored.
>
>When I once digged into the details I wondered whether it is correct to
>restore all the headers of the original request.
>E.g., if a user clears the browser cache while the browser shows the
>login dialog,
>the resubmit of the original request will not include an
>'if-modified-since' header,
>which was available in the stored request.
>In such a situation the servlet will see the header from the original
>request and could decide to return NOT MODIFIED status.
>
>The servlet spec does not tell you if this is correct behavior or not,
>but it may be interesting to know about this behavior.
>(And that's why we like open source projects where we can look how it
>really works :-)
>
>
>Regards,
>Matthias
>
>-----Original Message-----
>From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com] 
>Sent: Thursday, November 08, 2007 6:02 PM
>To: Tomcat Users List
>Subject: RE: j_security_check redirect after login
>
>  
>
>>From: Andrew R Feller [mailto:afelle1@lsu.edu] 
>>Subject: j_security_check redirect after login
>>
>>How does j_security_check know where to redirect users to after they
>>have logged in?
>>    
>>
>
>Read the servlet spec; to quote from SRV.12.5.3.1:
>"If the form based login is invoked because of an HTTP request, the
>original request parameters must be preserved by the container for use
>if, on successful authentication, it redirects the call to the requested
>resource."
>
>Unless you are going to muck around with Tomcat internals, what
>difference does it make how the above is accomplished?
>
>  
>
>>nor am I able to find out where in the Tomcat source 
>>code j_security_check is declared or invoked.
>>    
>>
>
>Start with org/apache/catalina/authenticator/AuthenticatorBase.java, in
>the invoke() method.
>
> - Chuck
>
>
>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>MATERIAL and is thus for use only by the intended recipient. If you
>received this in error, please contact the sender and delete the e-mail
>and its attachments from all computers.
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>  
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message