Login Question

[Mangler]

Can someone explain the how I can make it so that a login ( username )
can only be logged in once to a website if it is possible.

What I would like to do is have it so that if dwaldman is logged in
that login can't login again with another session until the old
session is terminated ( logged out )

 

[Evertjan.]

Jon Paal [MSMD] wrote on 09 jul 2008 in
microsoft.public.inetserver.asp.general:

..

should be very simple to add a check function in your login code to
verify the user session is active

if session("isactive") <> true then
'run login code
session("isactive") = true
end if

That would not help the OP:
"logged in once to a website" he writes, not to a session.

You would have to register the "being logged in" on the database,
or on a low volume site as an application variable.

The problem is you cannot easily detect a lost session,
that is not actively logged out,
but timed out or lost due to the browser or connection demize.

So you would have the new session login prohibit further use of the old
session login of the same user, methinks.

How to do that?

 

[Old Pedant]

The OP asked for a session test, and a lost session is the same as no session, so yes, session tests are valid.

Okay, you go try it then.

Use two different browsers (not just tabs in the same browser).

Login and set a session value from the first browser.

No go to the same web page with the second browser and try to see that
session value.

Won't happen. And yet that first browser's session is still perfectly active.

Now, close that first browser completely.

Where's the session now?

It can't be detected from the second browser. And yet it is *STILL ACTIVE*
on the server until the session timeout occurs.

So I completely disagree with your assertion that "a lost session is the
same as no session." Clearly *NOT* true on the server.

 

[Evertjan.]

=?Utf-8?B?T2xkIFBlZGFudA==?= wrote on 09 jul 2008 in
microsoft.public.inetserver.asp.general:

Okay, you go try it then.

Use two different browsers (not just tabs in the same browser).

Login and set a session value from the first browser.

No go to the same web page with the second browser and try to see that
session value.

Won't happen. And yet that first browser's session is still perfectly
active.

Now, close that first browser completely.

Where's the session now?

It can't be detected from the second browser. And yet it is *STILL
ACTIVE* on the server until the session timeout occurs.

So I completely disagree with your assertion that "a lost session is
the same as no session." Clearly *NOT* true on the server.

You are right, but the server cannot distinguish between a lost session
and no session at all from the viewpoint of the request for a new
session.

The best you can do is to store a session identification while logged in
at the server's user record, and so prohibit any action on the forlast
logged-in-session of that user if a new login is requested [because of a
possible lost session].

Prohibiting a second login till a timeout will aleniate your users that
lost the session.

 

[Old Pedant]

Evertjan: I was *agreeing* with you.

Yes, the only way to do this is to keep track in a DB or in Application
variables.

Well, I guess you *could* use Cookies (*NOT* session cookies...persistent
ones) if you trust your users to have cookies turned on. And I guess you
have to or sessions don't work.

So you'd simply persist the user's Session.SessionID in a cookie (give it an
expiration date of tomorrow, say?) and if the value from the cookie doesn't
match the value from Session.SessionID then you know it's an attempt to use
another browser window. I guess that works as well as the application or DB
saving, no?

What I have done in the past is allow the user to *OVERRIDE* the prior
sessionID. That way if they accidentally close the browser and come back in,
they can say "Yes, kill that prior session and use this one."

Hadn't thought of using cookies until just now. DOH on me. It seems the
obvious way, now!

 

[Old Pedant]

should be very simple to add a check function in your login code to verify the user session is active

if session("isactive") <> true then
'run login code
session("isactive") = true
end if

The point is, if the user ALREADY has ANOTHER session active, this code
won't discover that. So it can't possibly do what the OP requested.

 

[Anthony Jones]

Evertjan: I was *agreeing* with you.

Yes, the only way to do this is to keep track in a DB or in Application
variables.

Well, I guess you *could* use Cookies (*NOT* session cookies...persistent
ones) if you trust your users to have cookies turned on. And I guess you
have to or sessions don't work.

Not really. There are various levels of trust where cookies are concerned.
"Having cookies turned on" is nominally used to mean the user allows a site
store permanent cookies for at least the sites own use. Even with
"cookies turned off" session cookies normally continue to work since these
transient cookies stored only in process memory are normally still allowed.
It takes some agressive anti-cookie settings to disable session cookies.

 

[Old Pedant]

Too right you are. DOH on me. Heck, I often run with only session cookies
enabled when I'm surfing to unknown sites.

Okay, back to the DB or Application solution.

I used App solution in one case I worked on and then used the "allow user to
say new session is the correct one" paradigm. Worked fine & handled all the
users who would shut down browser without logging off & then come back again
in 15 minutes or so, before the old session timed out.

 

[Evertjan.]

Jon Paal [MSMD] wrote on 10 jul 2008 in
microsoft.public.inetserver.asp.general:

yes, by definition a session is relative to the browser.

I do not understand what a definition [whose definition?] has to do with
it.

A specific session under ASP is just that the server accepts new GT
requests as such. That usually present day browsers do not share cookies
has nothing to do with ASP.

If you transplant the session.id cookie to another browser, or to any GET-
request that has this cookie in it's header, the server would see that page
request as the same session.

Never tried it however.

 

[Old Pedant]

If you transplant the session.id cookie to another browser, or to any GET-
request that has this cookie in it's header, the server would see that page
request as the same session.

Sure. You can easily spoof ASP pages by just hanging onto the session
cookie and continuing to pass it back. ASP can't tell that it is "talking"
to a non-browser client.

But how is that relevant the original question?

 

[Evertjan.]

=?Utf-8?B?T2xkIFBlZGFudA==?= wrote on 11 jul 2008 in
microsoft.public.inetserver.asp.general:

Sure. You can easily spoof ASP pages by just hanging onto the session
cookie and continuing to pass it back. ASP can't tell that it is
"talking" to a non-browser client.

But how is that relevant the original question?

Not at all, it is relevant to the "definition" posed in the thread.

This is usenet.

 

[Old Pedant]

Not at all, it is relevant to the "definition" posed in the thread.

This is usenet.

LOL! VERY VERY nice! And funny!

I concede all points. Got me good!