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

Re: Login Question

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" <webmaster@repa irresource.comw rote in message news:dc858b15-ceeb-4165-a96f-10c8c62bcc38@s5 0g2000hsb.googl egroups.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.]

Re: Login Question

Jon Paal [MSMD] wrote on 09 jul 2008 in
microsoft.publi c.inetserver.as p.general:

"Mangler" <webmaster@repa irresource.comw rote in message
news:dc858b15-ceeb-4165-a96f-10c8c62bcc38@s5 0g2000hsb.googl egroups.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]]

Re: Login Question

">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==?=]

Re: Login Question


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

Re: Login Question

=?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==?=]

Re: Login Question

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==?=]

Re: Login Question

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

Re: Login Question

"Old Pedant" <OldPedant@disc ussions.microso ft.comwrote in message
news:B8CE9E20-CF5E-4AF5-A2B7-6C81767984EE@mi crosoft.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==?=]

Re: Login Question

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.

[Jon Paal [MSMD]]

Re: Login Question

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


"Old Pedant" <OldPedant@disc ussions.microso ft.comwrote in message news:3B72F89A-B1B7-4089-94AC-A95159DE9450@mi crosoft.com...

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

[Evertjan.]

Re: Login Question

Jon Paal [MSMD] wrote on 10 jul 2008 in
microsoft.publi c.inetserver.as p.general:

"Old Pedant" <OldPedant@disc ussions.microso ft.comwrote in message
news:3B72F89A-B1B7-4089-94AC-A95159DE9450@mi crosoft.com...

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

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

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

Re: Login Question

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

Re: Login Question

=?Utf-8?B?T2xkIFBlZGF udA==?= wrote on 11 jul 2008 in
microsoft.publi c.inetserver.as p.general:

>

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

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

Re: Login Question

"Evertjan." wrote:

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!