This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, I havent found a real solution for this problem, even when it is really common...
I have this context:
- JSF application running on Glassfish Server v3.1, JDK6. All in my personal computer with WinVista (This last should not be important).
- Using SSL and Basic authentication (Security of the container)
- I have done my logout() method in my backing bean invalidating the session and sending a redirect.
I can not make the container show again the Login box to validate the user, and be able to change of user... And my user always can go back, pressing the BACK button in the browser or just writing the URL, and continue doing thnigs there when is supposed that there should not be a existing session.
I am getting the name of the user the my backing bean is created:
And I use this name to perform operations...
Then for logout my xhtml has the code:
That calls this method in my bean::
I am declaring my backing bean with:
...Also I was doing the redirect from the the deployment descriptor... and it was the same.
If I close the browser the the session is lost and the container ask me again for user/pass.
This is one of those things where it helps to see what you're doing, but I have my suspicions, so let me explain How Things Work and see if they suggest anything.
The first thing to realize is that having a session isn't the same thing as being logged in, although to log out, you destroy the session. JSF tends to accentuate that, since it requires more use of session-scope objects than most J2EE frameworks.
The second thing to realize is that J2EE container-managed security is based on incoming URLs. If you submit an unsecured URL, you won't be prompted for login, but if you submit a secured URL, you will, regardless of where you jumped in from. And it's worth noting that it is the URL that's being secured, not the backing beans or other internal objects. This can cause grief in JSF, where the URL you use isn't always the one primarily attached to the View in question.
The third thing to realize - and this is probably where your problem lies - is that BASIC security is tied to your browser. There's really no way to log out of a BASIC security session except to shut down your browser. Not even closing the application window is sufficient.
This last item is one of several reasons why most J2EE container-secured apps use FORM based authentication instead of BASIC authentication.
An IDE is no substitute for an Intelligent Developer.
Alejandro is using J2EE's built-in Container Manager security system. It is always possible to tell if you're logged in under this system by simply looking at the HttpServletRequest. If the userId and UserPrincipal properties are null, the user is not logged in. Otherwise, the user is logged in. These properties operate in parallel, so when one is null, so is the other.
Your sample code omits something critical, which is the location of your "loggedIn" variable. It obviously isn't in the session, since logging out destroys the session. If you implement it as a backing bean property, the backing bean has gone out of scope when the session is destroyed. If you put it in a static class, a single instance would apply for all users, which would be a serious issue if you have more than one person logged in at once. And if you put it in a class instance, it's probably going to be shared in a multi-threaded environment, which leads to basically the same problem as putting it in a static class.
Joined: Apr 08, 2011
well thats true ... may be something can be done in Session Listener...
I believe the data can be collected here just before the session is destroyed... I am focusing more on how not to let the user go back into the previous loggedin mode after the logout (ofcourse it has some tradeoffs)
and I am totally with you on "There's really no way to log out of a BASIC security session except to shut down your browser".
Joined: Apr 08, 2011
One more option ... instead of using managedBean we can use ejb session bean as a one in JSF 2.0 and EJB 3.1 . That way , we don't need to go through managedbean at all and hence can get rid of the abovementioned shortcomings ....
Fidel Alejandro Torrealba V
Joined: Apr 08, 2011
Hi!!! Thank you so much for all your answers.
I took some days off... and did not reply this thread.
I just want to share my solution.
Basic authentication is bound to the browser, and once you have done login, should should close the browser to finish the logoff... what is not so elegant.
I changed to FORM authentication, creating my form, and posting the user information to a servlet who validates the user credentials against my realm, and this servlet redirect the user to either the application or to an error page. Obviously the proper configuration ifor security-constrain in web.xml have to be done.
I am sharing my solution here:
My validation servlet method:
And the required part of the configuration file....