File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes FORM based Declarative Authentication and Session Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "FORM based Declarative Authentication and Session" Watch "FORM based Declarative Authentication and Session" New topic
Author

FORM based Declarative Authentication and Session

Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
If we use the FORM based declarative authentication provided by server, when a user request a constrained resource, he will be prompted with the login page we specified in <form-login-page>.

My question is when will the server creates a session object for that login. Or is there any guarantee that the server will create a session object? If session is created, how the server relates one session object to a username (value returned by request.getRemoteUser())? The spec never mention the server should store a username attribute in the session object under any predefined name.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

There is no guarantee that a session will be created or that the lifespan of the session matches the lifespan of the login. ie if you assume the user is logged in and place their user info on the session, you'll be shocked when the session expires, gets replaced, and the session data expires while the user is still logged in.

It is typical for an application server to use the session to support authentication credentials but this is not always true. Websphere uses its own encrypted LTPA token cookie to manage credentials.

While there is little comfort in my post I hope it answers your question.

Dave
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
The raise a practical design issue. If my appli is using form based declarative security, and I want to prevent 2 simultaneous logins from the same user. For this we must somehow retrieve the login information currently maintained by the container and make sure any new login isnt the same as some existing login. But if there is no guarantee that session is used, how do we retrieve the login info?
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Alec Lee:
... and I want to prevent 2 simultaneous logins from the same user. ...


This topic has actually been discussed, in length, several times in this forum. Since the threads go into quite a bit of detail about the pitfalls of doing this in a stateless environment (which I maintain can't be done with any certainty), it would be worth your time to track them down and read them.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
We can use the application context in this case. We can store a collection of logged-in users in application context. And whenever we receive log-in request we can check those credentials against that collection object present in our application context.
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2053
How you implement the user and password is vendor-dependent; it is not in the specs. E.g. tomcat implements it differently from ibm websphere.

You can programmatically enforce the creation of a session.

You would also need to make sure that the session is maintained in between requests, via cookies, and other methods.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Adeel Ansari:
We can use the application context in this case. We can store a collection of logged-in users in application context. And whenever we receive log-in request we can check those credentials against that collection object present in our application context.


This will catch someone if they actually go through the login process twice but will do nothing to prevent someone from using CTL+n to open a new browser instance with the same session cookie.

Again, there is a thread that discusses this to death. If I get time later today I will try to find it and post a link to to it. If you're serious about doing this, it's worth spending some time searching this forum for previous discussions on the subject.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Ben Souther:
This will catch someone if they actually go through the login process twice but will do nothing to prevent someone from using CTL+n to open a new browser instance with the same session cookie.


I'm getting you, Ben. But where is the problem. Are we discussing to prevent user to share same session cookie or something.

Am I on the same page?
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
There is no guarantee that a session will be created or that the lifespan of the session matches the lifespan of the login. ie if you assume the user is logged in and place their user info on the session, you'll be shocked when the session expires, gets replaced, and the session data expires while the user is still logged in.


I am confused. But, one thing I am sure is that, according to servlet spec 12.5.3.1, if a user is authenticated using form and has a session created, invalidating the session means the user being logged out.

That means IF the container does create a session, it must associate the session with the login and cannot "expire while the user is still logged in".

I guess the main concern should be whether or not the container will create a session. There seems to be no rigid requirement from the spec.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Tell this to IBM next time you see them. WAS4 definitely does not do thi. I can't speak for v5
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: FORM based Declarative Authentication and Session