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  3136 
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 thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tom Loach |
last post by:
Our system administrator set up an NT server group in order to allow
our users to login to our application via https to our sql server.
The group appears as a User in SQL Server when you look at...
|
by: Michelle Stone |
last post by:
Hi everybody
I am writing a simple asp.net application using form
authentication. I store the list of all users and their
passwords in an SQL Server database table.
My client recently told me...
|
by: Bob |
last post by:
I haver a user login form (winforms app using vs2005 in VB.NET). After
succesfull validayion of user I want to open a first form and close the
loging form that was used, If I write
If...
|
by: luqman |
last post by:
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...
|
by: JodiPhillips |
last post by:
G'day,
I have a silly and simple problem that I need some guidance with.
Due to the way our network is set up, I am unable to use the group permissions for Access and have had to implement log...
|
by: satishknight |
last post by:
Hi,
Can some one tell me how to change the validation sequence for the code pasted below, actually what I want it when any one enters the wrong login information (already registered users) then it...
|
by: Gordon |
last post by:
I want to add a feature to a project I'm working on where i have
multiple users set up on my Postgres database with varying levels of
access. At the bare minimum there will be a login user who...
|
by: jerrydigital |
last post by:
Hello,
I have an edit user page that allows the user to view their user information and make changes if possible. I have a simple html login page that directs to an asp page called edituser.asp...
|
by: jerrydigital |
last post by:
Hello, I am having trouble getting unique user information on my account page. Currently, once the user logs in, it will only display "Welcome...(then the same name pops up no matter who logs in)"....
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
