[dba-VB] ASP.NEt 2.0: Forms Authentication: how to prevent using the same login *second* time from another PC when this login is in use in active session?

Jim Lawrence accessd at shaw.ca
Tue Dec 18 13:51:18 CST 2007


Hi Shamil:

Looks like a good plan. 

If the web server is either IIS there is a default web site inactivity
session timeout of between 120 and 200 seconds. That can be set to any
value, like 10 minutes or 600 seconds when the "Ebable HTTP Keep-Alives"
turned off (un-checked). So if there is no activity for an extended period
of time the connection and session is closed.

There are a number of other settings that can be set on the IIS to control
duration; See:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3
1a2f39c-4d59-4cba-905c-60e7af657e49.mspx?mfr=true for details.

If you tune up IIS for your application/web site that should handle most
events.
 
Do you have access to the BE server? Is this what you are looking for?

Jim    

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Tuesday, December 18, 2007 7:52 AM
To: dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] ASP.NEt 2.0: Forms Authentication: how to prevent
using the same login *second* time from another PC when this login is in use
in active session?

Hello Jim,

Thank your for your comments.
The ASP.NET 2.O's default time-out is 30 minutes. I can change it to 2 mins
but then it may become not user-friendly because while working with
Web-Forms users may have breaks and when they are back then they will have
their session closed...

...this means (for me at least) that subject issue doesn't have a "perfect"
solution and "workaround" solutions, which could be many, should be based on
agreement with the customer of the application under development...

...I currently got into agreement with the customer that this will not be an
issue to wait for 15-30 minutes for the users to login again if they
quit/abandon browsers without clicking explicit logout...

The solution could be also a JavaScript "talking to" server automatically
within given short time intervals (1 minute?) in background from client
browser using ASP.NET 2.0 callback feature
(http://msdn.microsoft.com/msdnmag/issues/04/08/CuttingEdge/ ) - then I can
set my ASP.Net 2.0 app' time out to 3 minutes (not 30 as it's now) and this
time-out will be a "sliding" one - IOW after each JavaScript's polling of
the ASP.Net server this time-out will be reset, if user abandons browser
without explicit logout then in 2 minutes their session will expire...

...on the other hand - if users will leave their browser running while
leaving for lunch, weekend etc. then their session will never expire - not
good from (at least) security reasons...

...and here we "go circles" again...

...then this automatic JavaScript polls/server code accepting these polls
should take into account were there any real page requests from the same
client/session between polls within say one-two hours (the maximum time-out
one wanted to have their browser idle but without "killing" server side
session) and if there were not such requests then such idle session should
be aborted...

...all above is too complicated to be true...

...the most user-friendly looks like to "kill" existing session when a login
with the same FormsAuthentication credentials happens - this should be a
rare occasion after all and this will not force users to wait until session
time-out expires...

...the only complication for the latter approach is that  Web application
keeping some state information should be ready to be "killed" any time - I
mean when they get "killed" they shouldn't leave the system  and back-end
database in inconsistent state - the "killer: should be able to "catch-on"
on the session it "kills"...

...yes, I know web applications should be better programmed completely
stateless - trying to achieve that here but not yet there - have to convince
customer to change the ways they usually work with desktop apps - I mean to
not expect the same "stateful" behavior from Web apps because "it's all two
blades sword" - you gain in one feature/functionality/usability issue - you
loose in another...


--
Shamil
 

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Tuesday, December 18, 2007 5:58 PM
To: dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] ASP.NEt 2.0: Forms Authentication: how to prevent
using the same login *second* time from another PC when this login is in use
in active session?

The length of a login session, through the browser should be controlled from
the IIS server. That by default has a 120 second inactivity session
time-out. It can be of course set to anything. This is usually in the
default web site through the IIS manager. This can be changed per web site:
properties > Web Site tab > Connection Timeout/ Enable HTTP Keep-Alives.

If for some reason you bale after login you may find yourself waiting to
login as the IIS server will not immediately know a connection session is no
longer active.

Jim         

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, December 18, 2007 1:03 AM
To: dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] ASP.NEt 2.0: Forms Authentication: how to prevent
using the same login *second* time from another PC when this login is in use
in active session?

Hi Shamil 

To me there is no reason to block another login of the same user - the
second login attempt may be perfectly legitimate - among others due to a OS
crash, the user has changed machine, or the user was interrupted and forgot
the first session.

A better method, in my opinion, is to check at login if a session with the
user credentials exists and, if so, pop a message similar to:

  It appears that you have already logged in. You can either 
  keep that session open and cancel this login, or 
  close that session and continue using this login.

That should cover all scenarios and should make sense for the user. It frees
you from time-out considerations and allow you - in the last case - to
simply kill the old session.

/gustav

>>> shamil at users.mns.ru 17-12-2007 22:41 >>>
Hi All,

I can't find answer/solution for the subject question: 

- isn't it built-in in ASP.NET 2.0 Forms Authentication? 
- Am I missing its description somewhere in MSDN or on Web?

Here is the issue I wanted to solve:

- Forms Authentication is used for and ASP.Net application;
- there are two (or more) test PCs;
- there are two (or more) testers using these PCs;
- these two (or more) testers have a set of shared test login/passwords
pairs;
- when a certain login/password is used by one tester then ASP.NET
application shouldn't allow to use it again from another test PC (or from
the same test PC but in another browser instance);
- on the other hand if the session where a certain login used expires then
obviously this login could be used on the second PC etc....

I'm looking and I can't find something like a simple function, which I
expected should have been built-in in ASP.NET Forms Authentication
(System.Web.Security.FormsAuthentication class or related classes)

1. DoesGivenLoginHasAnActiveSessionRunning(<loginName>)
...

ASP.ET does gave an event which fires when Session expires - this is
[Global.asax].Session_End(...) but it fires on time-out only, which is
usually about 20 minutes...

Now imagine that a certain login was used, and the browser in which this
login was used exited but ASP.NET application on server "doesn't know" yet
that the browser exited and this ASP.NET application has to keep continues
to keep application state related to login and until Session_End(...) fires
this state will be kept, and ASP.Net application will not let to login using
the same login, which actually has a "dead session" hanging on server...

I can implement "session hijacking & killing" IOW when the same
login/password is used while there is a live session running on server side
then this second login "kills" first session. That solution looks rather
simple to implement but is that the only option?

Am I missing simple solution of the subject issue? 

Thank you. 

--
Shamil



_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com

_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com

_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com




More information about the dba-VB mailing list