David Smith wrote:
j_security_check should never be directly referenced. Clients should
be requesting a secured resource. Tomcat then saves the request and
forwards the client to the login page (specified in WEB-INF/web.xml)
which in turn submit's authentication information to
j_security_check. Then tomcat restore's the original request and
forwards the client to the originally requested resource. This is all
per the servlet spec.
In otherwords, don't have anyone attempt to use your login page
directly as it won't work. When the login page hits j_security_check,
tomcat won't have a stored request, assume an old, timed-out login
attempt and respond as you've described.
correct, take a look at the Tomcat examples
Filip
--David
Rob Hunt wrote:
I have a form on a page that posts directly to j_security_check:
http://www.site.com/index.htm
<form method="post"
action="https://secure.site.com/j_security_check";>
<input type="text" name="j_username" />
<input type="password" name="j_password" />
</form>
When the POST request is received by secure.site.com, it kicks back a
408
response code and this message:
"The time allowed for the login process has been exceeded. If you
wish to
continue you must either click back twice and re-click the link you
requested or close and re-open your browser"
Now I know it's choking because no session has been established. But
why
doesn't j_security_check authenticate first and then attempt to set
session/cookies? Does anyone have a FORM based login workaround for
this?
Second question, what source module implements j_security_check?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
