[dba-VB] ASP.NEt 2.0: Forms Authentication:how to prevent usingthe same login *second* time fr

Jim Lawrence accessd at shaw.ca
Tue Dec 18 14:06:10 CST 2007


That is a good article... 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 9:02 AM
To: dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] ASP.NEt 2.0: Forms Authentication:how to prevent
usingthe same login *second* time fr

Hi Gustav,

OK, killing session when simultaneous FormsAutentication login with the same
credentials happens or wait 20 minutes this is one "programmers' nightmare"
issue, and here is another one:

- in IE7 (or FireFox 2.x +) you can open several tabs in one browser
instance and then all these tabs' windows will share the same session...

How about that "nightmare"?

I have got deployed here 

http://shamils-4.hosting.parking.ru/Sessions 

a sample from this article

http://www.stardeveloper.com/articles/display.html?article=2002102501&page=1


by setting session time-out for three minutes

    <sessionState  
      mode="InProc"
      cookieless="AutoDetect"
       timeout="3" />

just for testing purposes to see how sessions expire and how one browser's
instance tabs share the same session ID...

Now imagine a Web app having context (i.e. some internal state) and a user
opening several tabs in one browser instance and copying and pasting URL "to
see what happens" or to maybe do several tasks with the same Web app having
issues the *same* session Ids for one login, which could be working on one
task when this user switches and prepares another. When FormsAuthentication
added then user *will not* need to login again if he copy and paste URLs in
windows of the different tabs of the same browser instance...

Server side app will not be aware how many windows are opened on client side
without special measures...

What those measures should be to differentiate calls coming from different
windows having the same URL, same session Id, same Forms Authentication
cookie?

I currently see the only "simple" solution to have hidden HTML field(s) with
some IDs for every page returned from server to browser, and when browser
posts back such page then this ID expires and is changed to another, and
server side app has to keep track of these custom IDs, and when they are
sent via callback remove them etc.

...

--
Shamil
 

-----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 7:21 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 fr

Hi Shamil

That was my thoughts and conclusion.
And it does have that complication. However, at _any_ time the user can
"pull the plug" - in many ways with or without intention. I think that's the
programmer's nightmare all the time to consider "what happens at this point
if the user session is killed?". The user may loose data typed in, but the
app should not crash and stored data should not get corrupted.

Further, you cannot educate users to always logout clicking a button. As the
good guy I am I always try to do so, but in Hotmail you are redirected to
msn.com which I hate, thus I always close a Hotmail session by clicking the
close button of the window, and most users will do as well as they forget or
don't understand why not to do so.

Also, your client must be really nice and patient! Keeping a user logged out
for about 20 minutes if something happens will not raise popularity among
users. Again, users are impatient and will not understand why they can not
just log in again.

/gustav

>>> shamil at users.mns.ru 18-12-2007 16:52 >>>

<snip>

...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...

</snip>


_______________________________________________
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