I've posted this here, as it was the most relevant place I could find.
I don't think it should go in the JBOSS forum as it may be common across other Containers....
I'm writing a webapp, and have instructed JBoss/Tomcat to use our company's LDAP server for authentication.
As expected, as soon as I try to access any page, the browser asks you for a username and password, and when entered correctly, you are allowed to access the page. The server has authenticated the browser.
I now want to implement logout functionality, where once clicked, I will redirect the user back to the main page, and a new request for the username and password will be presented.
Unfortunately, I cannot find a way of achieving this, short of closing down the browser and restarting it. Invalidating the session gets rid of the session and all attributes, however the browser remains authenticated with the server. I've looked for cookies and the only one there contains the session ID.
Thanks in advance,
[ May 23, 2007: Message edited by: Mark Garland ]
For this situation it would be better to use form authentication instead of basic authentication. Then you can check for the existence of a valid session, and if none is present (since it was invalidated during logout), require a re-login through the login page.
I now want to implement logout functionality, where once clicked, I will redirect the user back to the main page, and a new request for the username and password will be presented...looked for cookies and the only one there contains the session ID
On the server side, you'll need something to indicate the client wants to loggout while the session is still valid.
2. Point to a different servlet where the session is invalidated and redirect...
Thanks for these replies.
Ulf - I really don't want to have to implement Form Authentication as I am trying to just protect access to an already written product with minimal changes.
Deva - I'm not sure what this achieves. I'm actually already using a Filter to intercept the request. However, there is a difference (I believe) between the session maintained by the container, and the authentication between the server/browser. I can invalidate the session (via a Filter or otherwise) and yet the browser still sends in my credentials (and so I still appear logged on).
Vu - There is no login page. Security is set so that any requests for resources require authentication, and the browser does this for us by showing its prompt for credentials. Unfortunately, invalidating the session does not make the browser 'forget' the credentials already entered.
Sadly, I'm starting to believe that Ulf is right when he says there is "no way".
Couldn't you simply use a filter to check whether the session is invalid, and if so, redirect the user to the login page? That way they would not remain "logged in".
Thanks for your reply.
My requirement *is* for the system to recognise the user is logged out.
This is how I see things working currently (correct me where I go wrong)
1) User tries to access protected resource
2) Server tells browser to authenticate them
3) Browser prompts user
4) User keys in details
5) User authenticated and gets access
The code of the product I am modifying uses httpServletRequest.getUserPrincipal(); to identify the currently authenticated user.
Now, for the first access, no session exists. The system finds this, and because the user has been successfully authenticated, creates a new session.
I can then invalidate this session when they select 'logout', however the user is *still* authenticated between the browser and server. The system finds that they have no valid session, thinks they are a new user, and creates a new session for them.
What I need is to be able to convince JBOSS (in this instance) to 'forget' this authentication (to forget that the user has ever keyed in details), and sadly it is looking like this is not achievable.
I'm sure you would have looked at the isNew() method on HttpSession - I suppose your last post on this thread means that you have found it to return true on sessions that have been invalidated. If that's the case, it sounds to me like a bug in either the JBoss API or the servlet spec.