Lets say someone logged in and leave the application as an idle and again using it. In the mean time the session was time-out. So, in this position session should be give null, but still it is displaying the assigned value in the JavaScript where as code behind showing null value.
Now what should I do?
You are describing a scenario where the user does not reload the page after the session expires, and hence the cookie value (assuming your session is cookie-based) is not removed/updated to reflect the new state of the session.
If you would like to update this in real time via your client-side code, you will have to check with the server by making a request on a set interval. The server-side handler should simply respond with the state of the session, and the client-side code should update whatever variables/cookies necessary to maintain state in your app.
This will introduce extra requests for users that are NOT idle, so then you would need some way to detect if a client is actually idle before triggering the request loop. Overall, you will need to evaluate if this "feature" is worth the extra requests and complexity that will be introduced.
Related
Let's say I have a button and onclick it changes components state to timer, so its state goes from 5 to 4,3,2,1 every second but if page is refreshed the value is lost since it is not stored anywhere and is rendering on client side.
How can I make this function value not to be lost when page is refreshed and be broadcasted to all users.
I do not want to use database since this function will be used a lot and would slow the db connection network also there might be a delay on database and timer would not update and server respond in time.
Any other method?
You need a server. You might not need a database, but if you're trying to share a global state, it needs to be stored somewhere that is not just a webpage. I'd suggest websockets. Every user could connect to your server, and when any of them hits the button, they'll all be informed, you can then kick off the timer in each browser, or send out second events from the websocket.
Let's say the timer is the same for all users. Really all you need to be storing server-side is a value for time zero. If you don't need to persist that value over server restarts (which needs a database), it could simply be a value in memory on the server. All the client needs then is to download this timer end value, and it can show the ticking client side by using a timeout.
Here is a new requirement that I need help with. Our users request that 2 minutes before the session timeout, warn them. (i can use a global javascript to check on every page since once a page is loaded, the session reset and by default, another 20 minutes is extended). at the 18th minute, a javascript popup shows up, asking the user "You have two minutes left before being logged off. Do you want to extend the session"?
Up to here, all is fine. But then once they hit "Extend it", then what? I don't want to refresh the page because the data they've already entered will be lost. Is Ajax needed? If so, what is the programmatic way to extend the current session? (not modifying web.config just to be clear)
Also, say they are talking to someone and did not see the javascript confirmation during the 2 minute. Is there anyway to "hold" the session, till the user decides to do something?
Thanks
I was recently working on a similar problem. With ASP.Net every call back to the sever resets the session timeout period. So a Ajax call is going to be your best bet.
As for holding the session, are you actually storing anything in the Session object that needs to be maintained? Or when you say session do you mean the period that the user is authenticated for? If it is truly Session and you are not storing data then it shouldn't matter id it expires. You may want to take a look ar the below link.
Forms authentication timeout vs sessionState timeout
This is in context to an ASP.Net application. The application makes use of a specific data which is set for a page. After this data has been set all the operations from this page onwards use the set data.
The problem is that if the user opens another tab with a competing data it overwrites the older data for the same session and for the same user which invalidates the operations on the first tab.
I know the suggested way is to refactor the code to remove such coupling but that is not possible. Here's another thread that discussed this but didn't specify any solutions other than refactoring the code (http://stackoverflow.com/questions/632062/ways-to-detect-ctrl-n-or-when-a-user-opens-a-new-window)
So, how can I detect (and notify the user) or stop the user from opening another tab - through javascript/Jquery?
You could set a session variable isActive and set it to true, along with all the other session data when the user opens the application the first time. After this, if the user opens another tab, check to see if isActive is true. If it is, inform the user and don't set the data again.
In pseudo-code, your logic should flow like this
if (!isActive)
//set session data
else
//alert the user: You have another active session
This would be a better solution because there is no guarantee the user does not visit the page to set the session, then temporarily turn off Javascript to launch a new tab without you being notified.
You should realize that you cannot prevent multiple pages being open on the same site by the same user. A user can always do such an operation using multiple different browsers on the same computer or browsers on different computers. As such, what you really need to do is to design your application to either just handle this situation gracefully or detect such a conflict and decide what the safest action is to take when it occurs (chances are, at the server, you either ignore the data from all sessions but one or you somehow merge them all together). What the safe action is depends upon what the data is or how it was changed.
The most straightforward option is to coin a new server-based session for the user each time the user visits and, at the server, invalidate all previous sessions so any older session that tries to make any future updates to the server will be denied because of an invalid session. This prevents any sort of multi-session data conflict.
If you want to be able to inform the user when their session becomes invalid, you could do a slow poll of the server (say once every 20 mins) as long as the window is open and on your site to check the session validity such that you can inform the user when their session has expired.
If there is a timeout set on one of our pages, and that same page is opened in another window/tab, is there a way to destroy/stop the timeout in the other window? We have employees who will use our system but open it again from their favorites. If they do this the already opened window will run the interval and then timeout. So while they are working in the new window they opened they will not be able to finish what they are doing because the other window timed them out.
Are there solutions to do this if a new window is opened?
In any sane web application, it is safe to have multiple windows open – especially in respect to session timeouts, because "session" state is managed by the server, not the client.
First, consider why web servers manage session state. HTTP was designed as a stateless protocol, which means any given request cannot conclusively identify who issued the request. This is fine for serving static resources, but is obviously not useful if we want to develop a more interactive app; Netscape later added cookies to their browser to address this.
Cookies solve the state problem (since the browser will issue consequent requests with the cookie[s]), but they are inherently insecure: a malicious client could modify a site's cookies. If, for example, upon login we set a cookie called uid to the user's ID, it would be trivial for someone to fake a cookie with uid=1, which might be your site's administrator account. Oops.
This is why web application frameworks invented the "session" construct. Each time a request is made with no cookie, the server creates a new (random) session key and sets the client's session cookie to that key. The web server keeps track of sessions and all state associated with each session. Important here is that the key itself contains no data, is large and random enough (has relatively high entropy), and is useless outside of your server. It is thus not possible to know how to change the key to gain access to other sessions.
Think of sessions as a large array – one item for each session, and a map of variables in that item. Conceptually, it might look something like this: (remember that this data resides on the server!)
session['safa4fwsa34rff4j9'] = { uid: 1, ... }
session['ajiokinmoi3235000'] = { uid: 4312, ... }
session['9lij34fff032e40k0'] = { uid: 9098, ... }
If I was signed in as user 1, my browser would send a cookie with sid=safa4fwsa34rff4j9. The server looks up this session, and passes the saved state ({uid:1}) on to your scripts. When your scripts are done, the server saves any changes back into its data store. (Session data is often kept in-memory, but in large sites, session data can be saved in a database.)
So what does all of this have to do with timeouts? This session data cannot be kept indefinitely because you'd eventually run out of storage space (whether that means running out of RAM or filling up the database your sessions are stored in).
Instead, the server also stores an expiration date & time with each session. Each time the session is accessed (by a client sending a request with the session's key), the expiration date is reset. The expiration date can be set anywhere from a seconds from now to years from now (depending on what server you're using). You configure how long you want your server to hang on to sessions; IIS defaults to 10 minutes, PHP to ~24 minutes.
In this model, the only thing that really matters is the last time a client issued any request, thus resetting his session's expiration/timeout. It wouldn't matter if multiple windows are open, because as long as one of them have accessed a page recently, all windows will still be active. If the session expires, then all windows are automatically expired when they make their next request.
Something that might muddy this issue is if you're doing some kind of AJAX polling, but the question doesn't indicate what technologies are being used. (#OP, it would be helpful if you included tags for your server stack.)
To summarize all of this: If you're doing any kind session management/expiration on the client, you're doing it wrong. Your app is likely insecure.
I have been working on having a instant messaging system on a website(kind of like Facebook and Gmail). I have javascript poll the server for new messages.
If the user has multiple instances of the site open is there any way to prevent each one from making requests?
You can assign each "new" load of the page with a UUID, and drop requests from all UUIDs that are not the most recent one for user. You need to send the UUID back in each request. If you want to get advanced, you can have the JavaScript on the page check the response to see if the server says it's an old UUID, and that it should stop making the requests.
Register each connection with a GUID generated on the fly in the browser. Check the GUID and the username pair to see which page was owner last. On page load, declare yourself a new window and that you're taking ownership. Sort of PageJustLoadedMakeMeOwner(myGuid, username)
Then have that GUID targeted frame update the server regularly for it's ownerness of the page.
If it stops updating the server, then have rules in the server that allow the next page to contact to take ownership of for that username.
Have pages that have lost ownership self-demote to only accessing once a minute or so.
The response to check if a given page is owner of that username is really fast. Takes almost no time to do, as far as the client is aware. So the AJAX there doesn't really restrict you.
Sort of a AmIOwner(username, myGuid) check (probably do this every five seconds or so). If true, then do the thing that you want to happen. If false, then poll to see if the owner of the page is vacant. If true, then take ownership. If false, then poll again in xx amount of seconds to see if the owner is vacant.
Does that make any sort of sense?
You could do something for multiple instances in the same browser, but there's nothing you can do if the user has multiple browsers. (Granted, not that common scenario)
If you still want to give it a try, probably the easiest way would be to keep a timestamp of the last request in a cookie and make new request only upon a certain threshold. You still might run a small race until the multiple instance s settle down, but if you use fuzzy time period for the polls, the instances should settle down pretty quickly to a stable state where one of the instances makes the call and the others reuse the result from the last call.
The main advantage of that approach is that the requests can be made by any of the instances, so you don't have to worry about negotiating a "primary" instance that makes the calls and figuring a fallback algorithm if the user closes the "primary" one. The main drawback is that since it's a fuzzy timing based algorithm, it does not fully eliminate the race conditions and occasionally you'll have two instances make the requests. You'll have to fine tune the timing a bit, to minimize that case, but you can't fully prevent it.