tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
Date Fri, 01 Aug 2003 11:03:39 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





------- Additional Comments From tfohrer@t-online.de  2003-08-01 11:03 -------

copied text from servlet-spec-2.4-pfd3 for container managed security with 
forms -> j_security_check

SRV.12.5.3 Form Based Authentication
The look and feel of the  login screen  cannot be varied using the web browser 
s
built-in authentication mechanisms. This specification introduces a required 
form
based authentication mechanism which allows a Developer to control the look and
feel of the login screens.
The web application deployment descriptor contains entries for a login form
and error page. The login form must contain fields for entering a username and 
a
password. These fields must be named j_username and j_password , respectively.
When a user attempts to access a protected web resource, the container checks
the user s authentication. If the user is authenticated and possesses 
authority to
access the resource, the requested web resource is activated and a reference 
to it is
returned. If the user is not authenticated, all of the following steps occur:
1. The login form associated with the security constraint is sent to the 
client and
the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the username and password
fields.
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the information from 
the form.
5. If authentication fails, the error page is returned using either a forward 
or a re-direct,
and the status code of the response is set to 401.
6. If authentication succeeds, the authenticated user s principal is checked 
to see
if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource using 
the stored
URL path.

Mime
View raw message