I wonder how gmail/Google keeps a user logged in even across sessions. And how (e.g. cookies) and what (e.g. time) do they use to decide to re-prompt the user for the login?
The short answer is that cookies do not have to expire when you close down the broweser or the machine they are on. Depending on constraints configured in the browser, if the server sets an expiry date in the future, the browser will continue to present the cookie until that expiry time.
C.
Well cookies are stored in your local machine, you can see those in totals -content settings -cookies.You can clear the cookies as well.So your information is stored there.More over about the sessions if they have been implemented on the websites...They could be destroyed by two methods ,one is by giving the time for session to expire the another way is when you forcefully want to expire the session then session abandon method is used.You must have seen sometimes if you don't scroll through a page for some time, then its written there your session has been expired. Sessions are executed on the server side and there values can be stored on the client side in the cookies as well.
Hope it would help you to understand William
Related
response.Cookies( SOFTWARE_PROGRAM_NAME).Expires = datetime.now.adddays(365*10)
this sets expiration for 10 years.
Anyway to set it for unlimited?
Cookies were intended to store temporary state information, like a token that identifies a shopping cart or user authentication session. User's can of course easily delete your cookie by clearing their browser cache anyway. If you want a cookie that lasts forever, you are never going to get it, and its not what cookies are for. If you want to store user-based information permanently, consider storing it in your database or other server side storage.
From RFC2109:
There are, of course, many different potential contexts and thus many different potential types of session. The designers' paradigm for sessions created by the exchange of cookies has these key attributes:
Each session has a beginning and an end.
Each session is relatively short-lived.
Either the user agent or the origin server may terminate a session.
The session is implicit in the exchange of state information.
I.e. cookies must expire because each session has a beginning and an end.
I've configured SQL Server to store session state (from here).
All I want to do is that when the user has logged into my application via browser A, I see that logged session when I visit my app from the browser B.
Right now that scenario doesn't work, I must log in one more time.
When browser B is opened (assuming it's a different browser altogether or a new instance of the same browser) a new session is created; therefore, what you see is expected behavior.
Also, I assume you mention this because you store in session some sort of key that indicates that the user has logged in successfully, correct?
If you want this behavior, you'd need to send some sort of authentication cookie with a long expiration date, you'd then read the cookie on the login page and consider the user as successfully authenticated, but keep in mind that this is a potential security risk.
How to tackle this session problem in ASP.NET,VB.NET?
The following requirement are there:
When the authorized user logs into the system that user is not allowed to login from another computer or in different browser other than that user is using right at this time.
The remedy we applied was: We have kept "Is_Loggedin" as a column with data type "bit" in a mst_vendor as a table name. When a user logs in we set the flag, Is_Loggedin, to "1" and each time when someone tries to log in using this account, the system is showing the error "The user is already logged in.".
When the user logs out it turns to "0" as the logout procedure calls as soon as the user clicks the log out button.
Problem scenario:
When the user closes the browser the flag remains the same, that is, "1".
When power gets off, it remains the same as "1".
If the session timeouts after a predefined value it remains the same.
There may be different scenarios other than this.
Is there any way so that we can store this internal flagging for the user's login status using the application object?
It may improve efficiency of the system and also eliminates the above problematic scenarios.
You should use the Global.asax file and use the Session_End function.
Session_End: Fired when a user's session times out, ends, or they leave the application Web site.
Store a datetime as another column next to the bit, and update it each and every time the user requests a page.
When a new user comes along with the same credentials and the bit is "1" you can check the datetime, and if it was a while ago you can be certain the user is no longer there. So let the login go ahead.
You could keep a pulse going in script, and when the pulse times out, consider the user finished with that session.
The benefit to this is that you can tell the difference between the user sitting idle on the site and the user leaving the site.
From a very top level view, here is what you can do
Use Cache with SlidingExpiration.
Everytime a user attempts login, check the cache with his username as the key. If an entry exists in the cache, you can say that user is already logged in and deny login.
If the key is not found, allow login and create a new key in the cache as the username and set the sliding expiration time. (This should be carefully chosen as this would be the duration, the user wouldnt be locked out after the browser is closed and user attempts to relogin.)
In the Application_PreRequestHandlerExecute handler in Global, check if the user is currently active (you can use sessions for this), reset the sliding expiration time for the user. This way, with each page request the cache expiration time would be reset.
If the user closes the browser and moves off, the cache would expire after the set period of time, and would free the user to log in again.
if in case the user attempts to login again before the cache expires, the user would have to wait for some time to let the cache expire.
if the user logs off properly, you can remove the cache entry on the logoff event such that user doesnt have to wait to relogin.
The Sliding expiration timeout can be synced with session timeout to emulate the actual session timeout for the application.
With this approach, you would also save on a lot of database round trips to update/check the user status and this would work irrespective of the hosting enviornment or the session modes.
Yeah, a script would be a good idea. Just set the session timeout to be 5 minutes instead of 20 and then write a method into session.end in the global.asax file that updates the database accordingly.
We have a web application with feature for logging in with credientials
The important requirement is once the user logs in he is not allowed to login from any other system or even another browser on same system
We used following solution which is mssql based : We have kept " Is_Loggedin" as a column with data type "bit" in a table. when a user logs in we set the flag as "1" sowhen someone tries to log again ,the system is showing the error "The user is already logged in"
When user logsout bit turns to "0"indicating user logged out.
However this logic is failing in following scenarios
Problem scenario:
When user closes the browser the flag is "1"and user is locked in or situations when user gets system problem and unable to log out
Is there a better logic to handle this requirement?
While the user is logged in, you could have a AJAX call that pings the server every 30 seconds that the user is logged in. Have a column Is_LoggedIn, and Last_LoggedIn for the date/time when they last sent that AJAX call. If it has been more than, say 1 minute, allow the user to login from another system.
You will also have a problem scenario if the user leaves their browser open for more than the session timeout period, usually 20 minutes. Then they will get logged out on the next request, but not be able to login again because of that is_LoggedIn set to 1. You would be better off doing some sort of time-based solution because keeping track of whether the user is still actively using a website is a very difficult problem because of the many ways they can leave the website without actually logging out.
If it is absolutely critical to avoid any chance of the user being logged in multiple places, you could also force all other places to logout automatically when the user logs into some new place.
You can update 'Is_Loggedin' flag to 0 at session_end event of global.asax.
session_end event is always call. session _end event call when session_timeout is expire.
in the global.asax code behind I believe there is an even for session end. You could tie into that method and set the user's Is_LoggedIn flag to 0. You would then also need to tie a user to a session key to be able to track a user's session.
Edit:
Also, the use of a session cookie or a normal cookie may help if the user closes their browser. The cookie would authenticate them upon re-opening the browser window; however this has a potential security hole if the user is using a public computer.
You could be to log the user out after sometime of inactivity (say 30 minutes). This way if the user closes the browser without logging out he will be able to log in again after 30 minutes.
Use Session_End as Pankaj suggest to make sure that the user's bit is set to 0 when logging out.
The issue with system failures is another problem. Maybe this could do the trick: When the user log in, the store the user's session ID in the database. When the user logs out, then clear the session ID. Every time the user makes a request you verify that the session ID matches the one stored in the database. If that is not the case, then invalidate the session, so that the user is logged out.
This should happen: If the user signs in, in another browser, the session ID would be updated. If user then goes back to the first browser windows and clicks on something, that session would be invalidated, and the user would be signed out automatically.
I am creating a content management system but there is one problem. What I want to do in my website is that when a user opens the website a new sessionid is created for that user, and when the user closes the website, the sessionid is cleared. How can I can do it?
There isn't a way to detect when a user closes your site or navigates away from your site. After a given period of inactivity (default 20 min), the user's session object will expire and be automatically cleared. I suggest checking out the MSDN article on Session, which will go over your options for tweaking your application's Session.
If on the other hand you're looking to perform custom logic when a user's session begins or expires (due to inactivity), you can add a Global.asax file to your application and use the Session_Start and Session_End methods for that.
That is basically the default behaviour of sessions in ASP.NET.
When a user closes the browser, the non-persistent cookie maintaining the Session ID will be dropped. This wouldn't actually expire the session, but since no reference to it will exist anymore, it will expire automatically within the default 20 minutes. Users revisiting your site after closing the browser window would have to use a new session. (Source)
An easy solution which works independently of Asp.net is to put timestamps on your session data and delete expired entries periodically.