![]() It also assumes you are using j_security_check:ġ) Define a welcome page directive that points to a login page this goes against what was previously said, but the key is to change the form post action to another mapping (e.g., auth.do). The proposed method assumes your web application's existing welcome page addresses a protected resource which subsequently brings up a login form page (it is ill-advised to point to the login page directly since successful authentication results in poorly defined resource redirection, 400 error, or perhaps blank j_security_check page). Trapping the 408 error in web.xml and returning to the login or setting an exceedingly long session time out are viable solutions, but neither convenient nor practical.Ī proposed solution is to provide an alternate login entry point which stores credentials to the session and autosubmits these credentials against j_security_check once a protected resource is accessed. This might be a common occurrence given the type of application. ![]() This probably happens because, as stated in Servlet Specification 2.3, "the original request parameters must be preserved by the container for use if, on successful authentication, it redirects the call to the requested resource." The result of this behavior is that if the user requests a protected resource, obtains a log in form, and lets the login linger for longer than the permitted session timeout, a successful authentication (or perhaps unsuccessful) will result in a 408 error. When using a login form to access protected resources (e.g., webmail application), Tomcat will return a SC 408 error to the user should the time period from initial resource request to login submission exceed the session-timeout element in conf/web.xml.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |