I came across this exact problem. In the mailing archives the
recommendation is to remove the action="j_security_check" from the login
form.
Here's what I did to implement the system:
1. created a index.jsp in the non protected folder. It contains a redirect
"<%response.sendRedirect("/protected/index.jsp");%>" to the protected main
page.
2. removed login.jsp from the global-web-application.xml <welcome-file-list>
and added index.jsp.
3. Made sure all my log-outs pointed to the non protected index.jsp.
What this does is that when a user goes to the site (e.g.
http://www.yoursite.com/) he is redirected to the protected index.jsp via
the non protected index.jsp. This causes the container to request
validation and pulls up the login.jsp. After successful password entry the
user is then redirected to protected/index.jsp. This seems to be working
without throwing up 404's now.
-----Original Message-----
From: Warren Hedley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 7:24 PM
To: Orion-Interest
Subject: j_security_check doesn't redirect but forwards content of
secure page
Hi folks,
I've been playing around with creating secure sections on an internal
website
using the J2EE web-application framework and Orion and have come across what
may
be a show-stopper for the application.
Basically, the user clicks on a link to a secure page, and if they're not
logged
in they are re-directed to a login form (using the FORM system) which is
generated by a JSP. When the user submits, they are directed to
j_security_check.
j_security_check serves the content of the originally requested secure page.
This is fine and seems to conform to the spec, but ....
If the secure page takes a while to load, then the user might be prompted to
hit
"reload". Because the URI in their browser is "/appname/j_security_check" or
whatever, they receive a 404. What's more, the back button takes them to the
login screen, and they have to click "back" again to see the original link
and
have another go at loading the original URI.
Would it not be better to have j_security_check send a re-direct rather than
simply forwarding the content of the secure page?
Does anyone have a decent workaround that doesn't involve something
inelegant,
like for instance, causing all secure pages to redirect to themselves on the
first load, or some such.
Thanks in advance,
Warren Hedley
--
Warren Hedley
Alliance For Cell Signaling
San Diego Supercomputer Center
