Second try: 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