Hello Max, > > One thing that I want to implement is providing > the > > login form within the home-page to make it a > > single-step job for them, so they'll see the login > > form on the side of the page when they first come > in. > > Otherwise there are two steps involved, first > click on > > the login link to go to the login form and then > submit > > the login form. How do you think I can do that? > > I don't know of an easy way to do that with > container-managed > authentication. The reason is that the caontainer > wants to decide when to > show the login form. If you always show a form, it > won't know where to send > the user when you submit. Tomcat chokes on this > (rightly so, considering the > spec) and WebLogic sends the user to the context > root or something like > that. > > I can think of a really ugly (and insecure) way to > have the login form on > every page with container-based security: > 1. user submits login form from any page > 2. server stores username/password in session and > responds with redirect to > protected page > 3. browser makes request for protected page > 4. server responds with login form that you > configured, which is setup to > send a redirect to > j_security_check?username=user&password=passwd if it > finds the username/password in the session (or > perhaps a pre-populated form > that will automagically submit itself) > 5. the server accepts the login and sends you to the > protected page, which > may just be a redirect back to the home page > > Holy crap is that a scary mess! You might be able to > clean it up a bit by > using HTTPS (for security), some sort of frames > setup (to lessen the chance > of disorienting the user as things flash by), or the > login form could have a > "We're processing your login request..." message > with the username and > password in a hidden form within the page that > submits itself when the page > finishes loading. That might keep the user from > freaking out when the screen > starts flashing and it takes a while for the login > (lots of back-and-forth > between browser and server). Okay, I am now of the > mind that this just might > work.
Wow!!! It is indeed scary.. but God bless you for solving this interesting problem. Yes indeed that would enable me to put a login form on every page. I hope you didn't have brain cramps while trying to figure this out. I kinda did earlier today while coming up with a different solution than yours, but less functional, although I think more secure since the password and username need not be stored in the session. 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. All I can say is I wish the servlet specs provided more methods to make it possible to log the user in through a method interface. Or maybe all they need to do is not requiring the login submission to j_security_check to happen only after the user has encountered a protected page. Simply, the user should be allowed to log in even before encountering a protected page. Maybe they should introduce a new sub-element in web.xml under login-config that declares from which pages a login to j_securiy_check could be submitted and make the login form portable rather than binded on a single page. That could be a viable alternative to providing a method interface cause again which a method interface for logging in a user, the app developer could poke holes in the security mechanism. So basically the key phrase is "make the login form portable". I'd appreciate hearing your thought on this. Perhaps I will make make a suggestion to the JCP about it. If you would like to help that would be great. Thanks, Mete > > Note: You can write a filter to mimic > container-based security that does > allow you to specify where to send the user after a > submit when the login > form was not shown out of necessity. I like the idea > of the app using the > methods defined for container-based security > (getRemoteUser(), etc.) because > they are standard and you can switch between > container-based an filter-based > with no impact to the rest of the app. We have done > just such a switch on a > project that I worked on, and it worked great. > > > Think about Amazon. You can either be logged-in > and > > not logged-in and it will still work. If you're > > logged-in the website treats you like a familiar > > customer, if not just default. That's the exact > same > > functionality that I'm trying to implement here. I > > hope this gives a wider picture of what I want to > do > > and perhaps you know a better way to do this than > how > > I was currently planning on doing it above. > > Yes, your app will work like that with this setup. > The login scope is the > context, and since both of your sub-apps are in the > same context, the login > state is shared between them. Just write your pages > to handle both the > authenticated and non-authenticated users. > request.getRemoteUser() will > return null if the user is not authenticated. > > -Max > > __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
