If user login with the login control in ASP.Net 2005 and then just close the
browser and then open the browser again, the login status shows, User still
Login?
Any idea, how to Logout the User when the User click on the Close Button of
Browser ?
I am using Sql Membership Provider for security.
Best Regards,
Luqman
20  3029 
A lot of times, the short-term cookie, such as the login cookie, can get
stored in IE's cache even after you close the browser. There is absolutely
no way that you can do anything when the user closes out the browser. The
thing to keep in mind here, once the browser fully loads the web page and
it's graphics, it is completely disconnected from the web server. There is
no notification that occurs when a browser is closed (or when a user browses
away from a web site) so there isn't a way to handle this type of event and
destroy the cookie.
--
Hope this helps,
Mark Fitzpatrick
Microsoft FrontPage MVP 199?-2006. 2007 and beyond
"luqman" <pe*******@cyber.net.pkwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
If user login with the login control in ASP.Net 2005 and then just close
the
browser and then open the browser again, the login status shows, User
still
Login?
Any idea, how to Logout the User when the User click on the Close Button
of
Browser ?
I am using Sql Membership Provider for security.
Best Regards,
Luqman
Are you sure you're not just talking about closing a tab? If you're talking
about closing the browser, it's very worrying and would need investigating.
As I understand it, login cookies are linked to a session id. Session Ids
are generated by the browser, so when the browser is closed, the session id
is lost. When the browser re-opens, a new session id is generated that
would not tie in with the cookie for the previous session, which will simply
die at the end of its timeout period. So you should not still be shown as
logged in when you return to the login page, or other page within the
application.
With tabs, on the other hand, the session is not lost when a tab is closed
and you will still be marked as logged in if you return to your
application - at least until the session times out.
HTH
Peter
"luqman" <pe*******@cyber.net.pkwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
If user login with the login control in ASP.Net 2005 and then just close
the
browser and then open the browser again, the login status shows, User
still
Login?
Any idea, how to Logout the User when the User click on the Close Button
of
Browser ?
I am using Sql Membership Provider for security.
Best Regards,
Luqman
"Mark Fitzpatrick"
There is no notification that occurs when a browser is closed (or when a
user browses away from a web site) so there isn't a way to handle this
type of event and destroy the cookie.
onunload
onbeforeunload
:) ??
re:
!onunload
!onbeforeunload
Those don't fire server-side, only client-side.
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Just D." <no@spam.pleasewrote in message news:e6**************@TK2MSFTNGP03.phx.gbl...
"Mark Fitzpatrick"
>There is no notification that occurs when a browser is closed (or when a user browses away from a web site) so there
isn't a way to handle this type of event and destroy the cookie.
onunload
onbeforeunload
:) ??
"Just D." <no@spam.pleasewrote in message
news:e6**************@TK2MSFTNGP03.phx.gbl...
>There is no notification that occurs when a browser is closed (or when a
user browses away from a web site) so there isn't a way to handle this
type of event and destroy the cookie.
onunload
onbeforeunload
You're not serious, surely...
--
Mark Rae
ASP.NET MVP http://www.markrae.net
Hi Luqman,
I've never run into this problem before.
When you're testing, make sure you close all of the browser windows; I
think that the temporary cookies don't get cleared out until all of
the browser instances are terminated.
Another approach to this problem it to make sure that your default
page is the main landing page of your application; .NET security will
redirect the user to the login page if they aren't logged in anyway,
so making the login screen the site's default.aspx is a bit redundant.
That way, if they are still logged in when they return to the site,
the user isn't presented with a login prompt while their status (say,
in the master page) reports otherwise.
POOF!!! Suddenly your bug became a feature... :-]
Good Luck.
-Mark
"Mark Rae [MVP]"
>>There is no notification that occurs when a browser is closed (or when a
user browses away from a web site) so there isn't a way to handle this
type of event and destroy the cookie.
onunload
onbeforeunload
You're not serious, surely...
Well, yes and no. Theoretically we can write some method conecting to the
server and making required steps. For example we can add one more page to
the app and redirect to this page if the user confirms that he wants to
close the session or the browser. This page will correctly close the session
letting the server know about that. It will be some kind of "Thanks" page.
If there is any other event like control click, then this method can be
easily disabled using on-page flag to avoid firing it on each page refresh.
Also we can analyze the new URL in JS and if the user leaves the app URL and
goes to new URL we can call the "Thanks" page as a popup, make all required
steps using this page and then just close it without any questions asked.
Since it was opened by the app it can be closed by the same app without
restrictions. How about that? Just an idea...
I'm managing the sessions in a different way, but I can't disclose this
method here, sorry.
Just D.
"Just D." <no@spam.pleasewrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
I'm managing the sessions in a different way, but I can't disclose this
method here, sorry.
LOL!
--
Mark Rae
ASP.NET MVP http://www.markrae.net
"Mark Rae [MVP]"
>I'm managing the sessions in a different way, but I can't disclose this
method here, sorry.
LOL!
It would be very funny if it didn't work for already several years without
any issues for over 500 sessions every morning.
Ysgrifennodd Mark S. Milley, MCSD (BinarySwitch):
Hi Luqman,
I've never run into this problem before.
When you're testing, make sure you close all of the browser windows; I
think that the temporary cookies don't get cleared out until all of
the browser instances are terminated.
Yes. I guess that could be it, as well. I must try that sometime.
Peter
Is there any command like user.logout which I can put in unload event ?
Best Regards,
Luqman
"Peter Bradley" <p.*******@dsl.pipex.comwrote in message
news:2d******************************@pipex.net...
Ysgrifennodd Mark S. Milley, MCSD (BinarySwitch):
Hi Luqman,
I've never run into this problem before.
When you're testing, make sure you close all of the browser windows; I
think that the temporary cookies don't get cleared out until all of
the browser instances are terminated.
Yes. I guess that could be it, as well. I must try that sometime.
Peter
Ok I found the problem, If the Login Control Remember Me is checked, then
user is not logged out, even the Browser is closed.
Best Regards,
Luqman
"luqman" <pe*******@cyber.net.pkwrote in message
news:O6*************@TK2MSFTNGP06.phx.gbl...
Is there any command like user.logout which I can put in unload event ?
Best Regards,
Luqman
"Peter Bradley" <p.*******@dsl.pipex.comwrote in message
news:2d******************************@pipex.net...
Ysgrifennodd Mark S. Milley, MCSD (BinarySwitch):
Hi Luqman,
>
I've never run into this problem before.
>
When you're testing, make sure you close all of the browser windows; I
think that the temporary cookies don't get cleared out until all of
the browser instances are terminated.
>
>
Yes. I guess that could be it, as well. I must try that sometime.
Peter
We don't as yet use the login control, but we were thinking of doing so. If
it is true that checking the Login Control Remember Me causes the browser,
effectively, to cache the Session, then I'd regard it - at first glance,
anyway - as a huge security hole: and we would definitely not consider using
this control, on that basis.
Is anyone in a position to confirm or deny this assertion (that the Session
is maintained even if the browser is closed), before we start trying to find
some time to do some checking on our own? We're very pushed for time here
and I don't want to have to find time for experimenting if someone already
has the answer.
Thanks
Peter
"luqman" <pe*******@cyber.net.pkwrote in message
news:eT**************@TK2MSFTNGP03.phx.gbl...
Ok I found the problem, If the Login Control Remember Me is checked, then
user is not logged out, even the Browser is closed.
Best Regards,
Luqman
"luqman" <pe*******@cyber.net.pkwrote in message
news:O6*************@TK2MSFTNGP06.phx.gbl...
>Is there any command like user.logout which I can put in unload event ?
Best Regards,
Luqman
"Peter Bradley" <p.*******@dsl.pipex.comwrote in message
news:2d******************************@pipex.net.. .
Ysgrifennodd Mark S. Milley, MCSD (BinarySwitch):
Hi Luqman,
I've never run into this problem before.
When you're testing, make sure you close all of the browser windows;
I
think that the temporary cookies don't get cleared out until all of
the browser instances are terminated.
Yes. I guess that could be it, as well. I must try that sometime.
Peter
Thanks. That's great. However, I read the MS article and can't see where
it refers to closing a browser and re-opening it. It talks about what
happens when Session.Abandon is called and what happens "when a user does
not log off from the application and the session state time-out occurs",
stating that "The application may still use the same session state cookie if
the browser is not closed". It also talks about re-using Session_Ids, but
with new Session states after Abandon has been called. None of this, as far
as I can see addresses the assertion that a user can close the browser and
then re-open it with login status preserved (i.e. still logged in), which is
what the OP is claiming, if I understand him correctly.
I didn't find anything relevant in your other link, either; but I confess I
only read the questions and not the answers. Perhaps you could point me at
the relevant bit?
Peter
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:es*************@TK2MSFTNGP04.phx.gbl...
"Peter Bradley" <pb******@uwic.ac.ukwrote in message
news:ue**************@TK2MSFTNGP03.phx.gbl...
>Is anyone in a position to confirm or deny this assertion (that the
Session is maintained even if the browser is closed)
Yes - Microsoft, in fact!
http://support.microsoft.com/?kbid=899918
This is also an intesting read:
http://forums.asp.net/p/7504/7504.aspx#7504
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
"Peter Bradley" <pb******@uwic.ac.ukwrote in message
news:Oj**************@TK2MSFTNGP04.phx.gbl...
Thanks. That's great. However, I read the MS article and can't see where
It was more of an addendum to show that sessions are not guaranteed to be
unique...
--
Mark Rae
ASP.NET MVP http://www.markrae.net
We don't as yet use the login control, but we were thinking of doing so. If
it is true that checking the Login Control Remember Me causes the browser,
effectively, to cache the Session, then I'd regard it - at first glance,
anyway - as a huge security hole: and we would definitely not consider using
this control, on that basis.
Sigh. The session isn't preserved.
First of all, all the session state data is stored on the server, not
the client, and since a session statebag can hold all sorts of objects
of unlimited size, it would be a colossal waste of resources on the
server. Secondly, if you were implying that the session would be
cached at the client, that's even more preposterous--HTML apps can
only write data on the client machine in the form of cookies (unless
some 3rd party control is involved) and a cookie is limited to 4KB, so
there simply isn't enough room to cache sesson data at the client--and
if that were the case, everything that you threw into the session
state would have to be serializable.
There are two different cookies going on here: there is the
FormsAuthentication Cookie, without which the .NET security wouldn't
work, and the Session Cookie, which simply holds the session ID.
The FormsAuthentication cookie needs to be present, and is checked by
the framework before authorizing access any secured resources. (By the
way, you can modify and enhance this behavior by adding a payload to
the UserData property of the FormsAuthenticationTicket, and tweaking
the application's Application_AuthenticateRequest subroutine in your
application's global.asax.) The data in the FormsAuth cookie is
encrypted, and the innerworkings of it are a bit beyond the scope of
this conversation, but let's just say that it magically preserves your
username and the fact that you were once authenticated successfully.
The session cookie simply contains a variable that is used to match up
the users session statebag (which always remains on the server) with
the current HTTP request.
The session cookie is temporary--it never even gets written to the
filesystem on the client--and it will be removed when the browser is
closed.
The FormsAuthentication cookie often DOES get written to the file
system--or at least, it can, based on your web.config settings.
Typically, I set the FormAuth expiration so it behaves like a session
cookie, because that is the behavior most people are used to.
What the "Remember Me" feature of the login control does is, on a
successful login, sets the FormsAuthentication cookie to not expire
for 50 days. That's all, nothing more.
So when you re-open the browser, Luqman, you are logging in, but you
are technically starting a new session. You can confirm this by
writing the session id out to the response; you should see a different
id every time you close all of your windows and open it.
Response.Write(Session.SessionID)
This can be a great feature, as long as your users (and your code)
expect it.
Happy Coding,
-Mark
Hold on there, cowboy. I'm the one who's asking for proof: not making the
assertion. Address your comments to the OP.
Peter
"Mark S. Milley, MCSD (BinarySwitch)" <ma*********@binaryswitch.comwrote
in message news:11**********************@n60g2000hse.googlegr oups.com...
>We don't as yet use the login control, but we were thinking of doing so.
If
it is true that checking the Login Control Remember Me causes the
browser,
effectively, to cache the Session, then I'd regard it - at first glance,
anyway - as a huge security hole: and we would definitely not consider
using
this control, on that basis.
Sigh. The session isn't preserved.
First of all, all the session state data is stored on the server, not
the client, and since a session statebag can hold all sorts of objects
of unlimited size, it would be a colossal waste of resources on the
server. Secondly, if you were implying that the session would be
cached at the client, that's even more preposterous--HTML apps can
only write data on the client machine in the form of cookies (unless
some 3rd party control is involved) and a cookie is limited to 4KB, so
there simply isn't enough room to cache sesson data at the client--and
if that were the case, everything that you threw into the session
state would have to be serializable.
There are two different cookies going on here: there is the
FormsAuthentication Cookie, without which the .NET security wouldn't
work, and the Session Cookie, which simply holds the session ID.
The FormsAuthentication cookie needs to be present, and is checked by
the framework before authorizing access any secured resources. (By the
way, you can modify and enhance this behavior by adding a payload to
the UserData property of the FormsAuthenticationTicket, and tweaking
the application's Application_AuthenticateRequest subroutine in your
application's global.asax.) The data in the FormsAuth cookie is
encrypted, and the innerworkings of it are a bit beyond the scope of
this conversation, but let's just say that it magically preserves your
username and the fact that you were once authenticated successfully.
The session cookie simply contains a variable that is used to match up
the users session statebag (which always remains on the server) with
the current HTTP request.
The session cookie is temporary--it never even gets written to the
filesystem on the client--and it will be removed when the browser is
closed.
The FormsAuthentication cookie often DOES get written to the file
system--or at least, it can, based on your web.config settings.
Typically, I set the FormAuth expiration so it behaves like a session
cookie, because that is the behavior most people are used to.
What the "Remember Me" feature of the login control does is, on a
successful login, sets the FormsAuthentication cookie to not expire
for 50 days. That's all, nothing more.
So when you re-open the browser, Luqman, you are logging in, but you
are technically starting a new session. You can confirm this by
writing the session id out to the response; you should see a different
id every time you close all of your windows and open it.
Response.Write(Session.SessionID)
This can be a great feature, as long as your users (and your code)
expect it.
Happy Coding,
-Mark
Hi Peter -
I didn't realize that I had to address my posts to anyone, this being
a group conversation and all. I'm not sure how I offended you, but I'm
sorry if I did so.
Bringing in the Herd,
-Mark
As long as the points being responded to are quoted,
the reply doesn't have to be addressed to the OP's post.
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Peter Bradley" <pb******@uwic.ac.ukwrote in message news:eG**************@TK2MSFTNGP06.phx.gbl...
Hold on there, cowboy. I'm the one who's asking for proof: not making the assertion. Address your comments to the
OP.
Peter
"Mark S. Milley, MCSD (BinarySwitch)" <ma*********@binaryswitch.comwrote in message
news:11**********************@n60g2000hse.googlegr oups.com...
>>We don't as yet use the login control, but we were thinking of doing so. If
it is true that checking the Login Control Remember Me causes the browser,
effectively, to cache the Session, then I'd regard it - at first glance,
anyway - as a huge security hole: and we would definitely not consider using
this control, on that basis.
Sigh. The session isn't preserved.
First of all, all the session state data is stored on the server, not
the client, and since a session statebag can hold all sorts of objects
of unlimited size, it would be a colossal waste of resources on the
server. Secondly, if you were implying that the session would be
cached at the client, that's even more preposterous--HTML apps can
only write data on the client machine in the form of cookies (unless
some 3rd party control is involved) and a cookie is limited to 4KB, so
there simply isn't enough room to cache sesson data at the client--and
if that were the case, everything that you threw into the session
state would have to be serializable.
There are two different cookies going on here: there is the
FormsAuthentication Cookie, without which the .NET security wouldn't
work, and the Session Cookie, which simply holds the session ID.
The FormsAuthentication cookie needs to be present, and is checked by
the framework before authorizing access any secured resources. (By the
way, you can modify and enhance this behavior by adding a payload to
the UserData property of the FormsAuthenticationTicket, and tweaking
the application's Application_AuthenticateRequest subroutine in your
application's global.asax.) The data in the FormsAuth cookie is
encrypted, and the innerworkings of it are a bit beyond the scope of
this conversation, but let's just say that it magically preserves your
username and the fact that you were once authenticated successfully.
The session cookie simply contains a variable that is used to match up
the users session statebag (which always remains on the server) with
the current HTTP request.
The session cookie is temporary--it never even gets written to the
filesystem on the client--and it will be removed when the browser is
closed.
The FormsAuthentication cookie often DOES get written to the file
system--or at least, it can, based on your web.config settings.
Typically, I set the FormAuth expiration so it behaves like a session
cookie, because that is the behavior most people are used to.
What the "Remember Me" feature of the login control does is, on a
successful login, sets the FormsAuthentication cookie to not expire
for 50 days. That's all, nothing more.
So when you re-open the browser, Luqman, you are logging in, but you
are technically starting a new session. You can confirm this by
writing the session id out to the response; you should see a different
id every time you close all of your windows and open it.
Response.Write(Session.SessionID)
This can be a great feature, as long as your users (and your code)
expect it.
Happy Coding,
-Mark
This discussion thread is closed Replies have been disabled for this discussion. Similar topics
2 posts
views
Thread by Tom Loach |
last post: by
|
5 posts
views
Thread by Michelle Stone |
last post: by
|
3 posts
views
Thread by Bob |
last post: by
|
reply
views
Thread by luqman |
last post: by
| | | | |
9 posts
views
Thread by Gordon |
last post: by
| | | | | | | | | | | | | | | | | | | | | | | |
