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 )

[Jon Paal [MSMD]]

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

if session("isacti ve") <true then
'run login code
session("isacti ve") = true
end if
"Mangler" <we*******@repa irresource.comw rote in message news:dc******** *************** ***********@s50 g2000hsb.google groups.com...

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.publi c.inetserver.as p.general:

"Mangler" <we*******@repa irresource.comw rote in message
news:dc******** *************** ***********@s50 g2000hsb.google groups.com.
..

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

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

if session("isacti ve") <true then
'run login code
session("isacti ve") = 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?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jon Paal [MSMD]]

">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 )"

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

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

"Jon Paal [MSMD]" wrote:

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?T2xkIFBlZGF udA==?= wrote on 09 jul 2008 in
microsoft.publi c.inetserver.as p.general:

>
"Jon Paal [MSMD]" wrote:

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

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.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

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...persi stent
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.Session ID 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.Session ID 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!

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

"Jon Paal [MSMD]" wrote:

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

if session("isacti ve") <true then
'run login code
session("isacti ve") = 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]

"Old Pedant" <Ol*******@disc ussions.microso ft.comwrote in message
news:B8******** *************** ***********@mic rosoft.com...

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...persi stent
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.
--
Anthony Jones - MVP ASP/ASP.NET

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

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.