That leaves me with the initial questions. In the meantime, I checked again my app with the following results:
1.) Start of the application (index.html with the link to a CMS-protected area)
Result: no cookie yet set, and hence no session established
2.) Klick on the link to the protected area. As a result not the welcome.xhtml is loaded but login.html (declarative security)
Result: a cookie is set, in the specific test with value 50033e41d18d500e302036f6eb74
3.) Enter credentials and submit form; welcome.xhtml of the protected area is loaded
Result: a new session is established (I assume that is the security session) with cookie value 500736ddf603308a1e58f032b08e
4.) Logout again. session.invalidate() is called. Again index.html is loaded.
Result: Still the same cookie is set on the client: 500736ddf603308a1e58f032b08e
5.) Click again on the link to the protected area
Result: welcome.xhtml is opened but without information from the backing bean and a new session is established with cookie value 502f6e71e4ca1580e9761cf8d983
So, questions:
- After step 4 I would have assumed the cookie to be deleted. A possible explanation for that behaviour could be that the server is deleting the session only on the server but not on the client. That means the cookie is still available on the client but without a corresponding session on the server. Is that understanding correct? If not, why is the session still existant, although session.invalidate was called?
- What can be done to avoid after step 5 the loading of welcome.xhtml? What would be a "good" way to solve that?
- Where can I find more info/readings/books about the mentioned security context (UserPrincipal and remoteUserId) - to get deeper into the subject?
Regards,
Dom
