Hello again Mete, ;-) I like this stuff. It's like a puzzle.
> Basically I made my welcome-page a dummy page that > redirects the request to /login.do. I made /login.do a > protected resource and what is ironic is that I made > my home page the "login page" !! (in <login-config>). > This kinda turns container-managed authentication on > its head since the protected page becomes the login > action while the login page becomes the homepage. But > surprisingly it seems to work. So when the user goes > to the page, after a redirect they arrive at the home > page. On the home page, they can either fill in the > login form and submit, or click on any one of the > other links in which case the authentication process > is dropped and the user is let go to other unprotected > pages. While this may seem like another big mess, it > satisfies the container since the form-based > authentication is done normally. That is a clever setup, but I don't think it will work quite as intended under certain circumstances. When someone follows a link into the site and then tries to login, they will run into trouble. For instance, say Joe sends a link to /deep/in/site/somethingCool.do to his friend Ann. Ann follows the link and browses around for a while, and then decides to login. She enters her username and password and submits the login form in the page margin. Bang! Server error. Actually, on WebLogic, she will be taken the home page (or get a 404 error, depending on where she is in the site) without getting authenticated. On Tomcat, she'll get a server error. The problem is that the server received a j_security_check submittal before it sent the user to the login page. You might take the position that everyone should enter through the home page, but in reality this problem will pop up even for people that bookmark the home page (/index.do, for instance) and go to the site via the bookmark, or follow a link from a Google search results page. And the web loses much of its value if you can't link to pages within the site, even for intranet apps or web apps where you might want to send URLs to your co-workers or employees via email. You might be able to partially fix this behavior with some more trickery: 1. put something in the user's session if they visit the site home page (/index.jsp) 2. on every page (including the home page), check for the presence of the "home page marker" described above, if it isn't there put the current URL in the session and redirect them to the /login.do page, which will force the container security to jump in and redirect them to the home page (which is configured as the login page)... 3. in the home page, set the marker as usual but also check for a URL in the session, and if it is there remove the URL from the session and redirect them back to that URL The only bad effects you'll up (that I can think of) with this are: 1. there will be some delay from the redirecting when users first try to follow a link into the site 2. they will always end up at the home page (after being redirected there from /login.do) after logging in You can probably fix #2 by with even more trickery if you are feeling particularly industrious. If you can live with a short-term compromise of having a login link on every page rather than a login form, the first design I sent out should work for that. I have written a security filter that allows you to submit a login form without having been forced to the form. You then just configure the filter with a URL to dump users to after they authenticate themselves. Perhaps I should allow you to optionally configure the filter to remember where you submitted the form from and return you there upon successful authentication (a task for version 1.1). Anyway, I am in the process of preparing it for release (i.e. it works and I'm cleaning it up). -Max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
