I read some sources of the server, it seems the server only registers the users to requests when they access protected resources firstly.
I wonder why the server behaves in this way. If I want to allow users login to the application directly, any suggested workaround?
[ November 03, 2008: Message edited by: Stephen Suen ]
Originally posted by Paul Sturrock:
I'm trying to think why you might want them to do this; any reason?
Thanks for the reply.
For example, I want to put a small login form on the top of pages, allows user to submit login form directly as they will, even they never acccess protected resource before this.
Any way, users must access some protected resources so they can submit a login form. This really confused me. I think this behavior will make so many common seen pages difficult to be implemented.
[ November 04, 2008: Message edited by: Stephen Suen ]
Originally posted by ou yang:
i remembered a person who have the analogous the question.you would use a filter,the user is not logged in.but they access a protected source then he will be redirected to login page.Once he has successful login in,the user is redirected to the original source page.do you want to do like this?if yes,i will send an example to you .my skype username is xuexishijie,you can add me or send email to me.
For FORM authentication, when unauthenticated users request a protected resource, they will be redirect to login form page, after successful authentication, they will be redirect to the original requested resource. That works for most circumstances. But, if the user goes to the login form directly and submit username/password correctly, he will be authenticated, but not authorized, because the container won't register his principle and role membership to the request object (request.getRemoteUser() == null). This behaviour prevent web application designer from some really simple designs, such as presenting a page with a login box on top of it to allow users login any time they will.
There must be some reasonable consideration the container behaves in this way, but what's that? and any workaround?
Look forward answers
/index.jsp (simple welcome file not protected)
/Login.jsp (login page)
/manage/ManageAccount.jsp (some protected resource)
1. request /Login.jsp directly and submit login form
2. authenticated, redirect to the context root, /index.jsp
3. request /manage/ManageAccount.jsp
4. fail and redirect to /Login.jsp
5. click the browser's "Back" button, go back to /index.jsp
6. request /manage/ManageAccount.jsp again, succeed
How could this happen? I'm working on glassfish-v2ur2, using FORM_AUTH with a custom realm for my JSF application.
I read some source code around FormAuthenticator. It seems the server uses some kind of session cache for saving user principles during authentication. Is there any possibility that the above problem comes from this mechanism, or is it just some bug existed in my application?
Thanks for any reply.