Login Question

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


"Mangler" <webmaster@repairresource.comwrote in message news:dc858b15-ceeb-4165-a96f-10c8c62bcc38@s50g2000hsb.googlegroups.com...

Quote: 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] wrote on 09 jul 2008 in
microsoft.public.inetserver.asp.general:

Quote: "Mangler" <webmaster@repairresource.comwrote in message news:dc858b15-ceeb-4165-a96f-10c8c62bcc38@s50g2000hsb.googlegroups.com. .. Quote: >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("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?

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

">What I would like to do is have it so that if dwaldman is logged in

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

"Jon Paal [MSMD]" wrote:

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

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

Quote: > "Jon Paal [MSMD]" wrote: Quote: >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)

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!

"Jon Paal [MSMD]" wrote:

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

"Old Pedant" <OldPedant@discussions.microsoft.comwrote in message
news:B8CE9E20-CF5E-4AF5-A2B7-6C81767984EE@microsoft.com...

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


--
Anthony Jones - MVP ASP/ASP.NET

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.

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


"Old Pedant" <OldPedant@discussions.microsoft.comwrote in message news:3B72F89A-B1B7-4089-94AC-A95159DE9450@microsoft.com...

Quote: "Jon Paal [MSMD]" wrote: Quote: >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.

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

Quote: "Old Pedant" <OldPedant@discussions.microsoft.comwrote in message news:3B72F89A-B1B7-4089-94AC-A95159DE9450@microsoft.com... Quote: >"Jon Paal [MSMD]" wrote: Quote: >>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. > 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.



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

Quote: 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?

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

Quote: > Quote: >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?

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

This is usenet.


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

"Evertjan." wrote:

Quote: 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!