Session management in web app

[Guest]

Hi,

I have a web application in which I need to restrict user access to 1
session per user. I've done this my creating a cache entry when a user logs
in, and checking on subsequent logins for that entry, and refusing access if
the user is already present.

However, this gives me a problem if the user forgets to log out, as they
then need to wait until the session time out before they can log in again.

I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.

Thanks in advance.

 

[Guest]

You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.

If you mean client side, you have to emit the JavaScript necessary to cause
a postback.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

Sorry if I'm missing the point here, but this answer doesn't seem to have any
relevance to my question.

Can anyone either expand on this answer, or give me an alternative?

Thanks

 

[Kevin Spencer]

There is something amiss with your requirements. First, your original
requirement is that there is only 1 Session allowed per user. This would
prevent a second user or the same user from loggin in during that Session,
via your mechanism of denying access to another user, or another instance of
the same user.

Now, your client wants you to add another requirement which contradicts the
first: Instead of refusing access to the second user, you kill the first
user Session, and allow access to the second user, effectively hijacking the
first user Session.

You need to inform the client of this contradiction. He can't have it both
ways. Either a user is restricted to a single Session, or the user is not.
If the user does not log out, the user must wait for the Session to end.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Guest]

The original requirement was to only allow 1 session per user. This is
implemented. However, as I said, if the user forgets to log off and just
browses away or closes the browser, then they are unable to log on again
until the session expires.

What this specific client wants to to limit to 1 session per user. If the
same user tries to log on a second time, then, rather than saying "you are
already logged on", they would prefer us to kill any active sessions for that
user, then create a new session for this new logon. Still one session per
user, as all the older ones are terminated.

This is something that has been recommended to them by a net security
testing firm, not something I particularly want to do. Sounds like a horrible
user experience to me personally...

 

[KMA]

Maybe I'm being thick, but why not just abandon the session and create a new
one as the first action when the user pushed the log on button. If its the
first log on then no harm done, and if its a subsequent log on then the
sesion doesn't have any stale data still populating it.

 

[Kevin Spencer]

Well, Simon, in that case, there is no need to do anything with the original
Session. It is unavailable anyway. When they log in again, they are already
in a new Session. Anything in the old Session is history.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Juan T. Llibre]

re:

I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.

You don't need to access a session by ID to do that.

Just include a Session.Abandon command before the client logs in.
If the session for that user's browser is still active, it will be killed.

If the user logs in from another workstation, that won't help, of course.

 

[Guest]

The problem is that I am limiting to 1 session per user purely by storing a
token when a user logs on. So, if they try to log on again (from a different
client) I check for the presence of the token on the server, and deny if it
is present.

If I just delete the token and allow them to log on, then this doesn't do
anything to the original session on the original client; it creates a new
session for this new logon, but the old session is still available and active.

 

[Juan T. Llibre]

Sounds like your client is a control freak who
feels the need to nanny his numbskull employees.

;-)

A little user education would work wonders here.

Your client should instruct his employees not
to login twice from different workstations.

Quite simple.