we've implemented a system similar to the one described in this other SO post. Basically, if the user doesn't do anything for 14 minutes, we prompt them that they will be logged out. If they click on "keep me logged in" we do an ajax request to keep their session alive, otherwise, they are redirected to the logout page after a minute.
It works pretty well, and is inline with similar systems employed at sites like mint.com and bankofamerica.com. The only problem is that our application's users tend to have multiple tabs open to refer back and forth to different pieces of data. So the problem is that they may be actively working in one tab, but then the other tab times out and logs them out. This causes an abrupt session timeout for the user when they were not expecting it. btw, mint.com has this same issue.
So I was wondering if anyone had any ideas to combat this?
I have one idea, each request could set a "last active time" cookie. Upon auto-logout, the server could check this last active time and if it's relatively recent, avoid logging them out. The manual logout would of course ignore this cookie so if the user wants to log out he can do so at any time. However, I'm afraid that this may be exposing some sort of security risk that I'm not able to see at this point. Thoughts?
Before showing the pop-up, ask the server how long ago the user has done his last request.
Related
I have a Grails based web app which uses Spring Security to handle user logins etc. I have hit a bit of a block and am hoping the more experienced might be able to point me in the right direction for a solution.
The application has the concept of messages which can be sent from user to user to provide a instant messaging feature. There is a timed Ajax call that is present throughout the system which is used to alert the user of any new incoming messages.
My problem is that since I have implemented this, each time the ajax call is performed, of course the users session is being refreshed, therefore never timesout. So a manual 'log out' is the only way they can log out, whereas before expiry of a session would redirect them to the login page.
Does anyone know how I can still accomplish automatic logouts whilst still have the timer functioning?
I'm hoping I can set up some kind of filter with spring security, or perhaps there's an annotation I can use on the periodically called method to instruct it NOT to refresh the users session.
As always any help & comments are appreciated.
Thanks to Long for pointing me in a different direction with his comment, I believe I have now a much better, more intuitive user friendly solution.
Rather than trying to change things on the backend, I am using a little jQuery script which is very easily configured and fits in perfect with my app which already uses jQuery and the jQuery UI.
After a specific period, a jQuery dialog pops up, modally dimming the background and informs the user due to inactivity they will soon be logged out. A progress bar is displayed which reduces until it is empty at which point if the user hasn't click my 'Continue Working' button, then I change the window location to the spring security logout controller URL, taking them back to the sign in page. It works beautifully and is very easy to configure.
The instructions can be found here : http://kenbrowning.blogspot.co.uk/2010/04/are-you-still-there.html
Kudos to Ken Browning for his library.
I have a requirement to inform every user to save their work and logout so that admin can reset iis or do some changes in the asp.net MVC application server.
looping through session object collection is not thread safe that is what i have learned.
any other ideas?
and even if i can get hold of active sessions how do i send a message to those clients ?
thanks in advance.
Save the message in a database and query the database for every request to see if a message exist.
This seems like a poorly-defined requirement.
Serious maintenance should be done at a specific time, and users should be alerted to that time window well in advance.
Simply restarting IIS is a pretty quick procedure... is there any reason users would lose their work when simply restarting IIS? While I've been filling out this StackOverflow answer, for instance, they could have restarted the server a dozen times. Once I hit Post, if the server is down, it'll either timeout and leave my work in the textarea, or else it will connect successfully if the server is back in time.
If I'm not submitting data, but just clicking a link, the same applies: either the browser times out, in which case a simple refresh is enough once the server is back up, or it eventually takes the user where they want to go.
If you're doing pure AJAX requests you will need to handle a missing server yourself, rather than relying on the browser to do it, but you'd need to work that out anyway because of the Eight Fallacies of Distributed Computing #1: "The network is reliable." (see http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)
So, I'd actually push back on that requirement. They're asking you to do something that won't really meet the need (users don't lose data, have a reasonably good experience), that will become complicated, and that will be a brittle solution in the end.
Sounds like a case for SignalR!
https://github.com/SignalR/SignalR
Occasionally when we go from the "Export Grades to SIS" link in D2L back to our SIS, using the REST API in our SIS to get the grades from D2L, somewhere in the going back and forth between systems, the browser gets lost and simply goes blank. I think the problem is happening in the final hand-off from D2L to our SIS--that seems to be the point where the browser loses track of where it is. When this happens, our SIS continues to act as if it thinks everything is still working correctly--it does pull grades through the REST API, and does everything it is supposed to do. But the browser session has gone blank, and never shows anything from either D2L or our SIS after that, so the user will not know what is going on.
This happens roughly one out of every 6-8 times we test the link between D2L and our SIS. I don't see a definite pattern, at least not yet.
Any ideas what we are doing wrong? What sorts of things should we be looking at to try to determine where the browser is getting lost?
If it is an operational issue with a server it is probably best to open a support ticket with Desire2Learn.
We are looking at setting up an internal web application (ASP.NET MVC) as a kiosk for the employees that don't have a dedicated computer. We currently do not have this kiosk setup. Each employee will have their own login to look at some basic payroll information and request leaves of absence. This same web application will be used by the office workers with a dedicated PC at their desk.
I am going to go out on a limb and say that no matter how many times we tell the employees, the employees will not click log off when they walk away from the kiosk. What would you do to help prevent this from happening?
lets try to fix the users instead of the code :) , i guess that your log out button is like the one here on stackoverflow. its a little text link "logout" some where in the upper right corner. thats perfect for people who use webapps day by day and are aware of the fact that they need to logout before someone comes along a does havoc to thier facebook profile, but less tech savy users wont think of that and walk away.
you need to the get the attention of your users to this logout-button and teach them that logging-out is a good thing.
try the following
give the logout button more visual weight then usally make it bigger, make it a real button instead of a textlink and even change its color to something more alerting (red, orange, ... whatever fits your ci)
if they dont loggout, use the session timeout and some javascript the refresh the page after any amount of inactivity, but also set a flag that this user has not logged out after his last visit. that way you can greet him on his next login with a nice confirmation dialog, and tell him once again why logging out is so important and where your logout-button is located.
The naive solution would be to enforce a timeout. If there's no activity from the user within a certain time limit (say, a minute or so), log them out. Of course, this won't prevent someone from walking up immediately after an employee is done and seeing how much money they make.
ATMs handle this, I think, by timing out after a minute or two, which isn't super-secure but at least offers some minimal security.
If the employees have any kind of RFID card or other security token, you could require them to put it in a reader slot, and log them out whenever the card disappears. Handling this within a web app, though, could get complicated.
The simple way is to use a little javascript.
Just have it set to something like 30 seconds of inactivity. If the user hasn't clicked on anything have the javascript send it back to a login page.
Here's a link to get you started.
Assuming you've already thought of the obvious (aggressive session timeouts, non-persistent authentication cookies, etc); how about a bit of an "out there" suggestion?
I'm not sure how do-able this would be with a web-based interface; but what about using some form of IR sensor with a usb/serial interface and an API you can tie into? This may make it possible to invoke some form of "logout" operation when someone walks away from the kiosk.
Perhaps someone has a better suggestion for external hardware, but this was the first thing that lept to my mind as a out-of-the-box approach.
I found a jQuery version that seems to work quite well. I'll start by using that and see how that goes.
so I have designed this voting thing which does not let somebody vote for the same article twice in 24 hours. However, suppose a person votes and after seeing the person was able to cast vote or that he is falling in that 24 hour window, I disable the vote-casting button (and this is all Ajax btw).
But what to do when a person closes his/her browser and comes back up or even refreshes the page? Obviously, he would not be able to cast vote, because of my algorithm, but the person would still end up succeeding in making call to the server. So if he really wanted, he would keep refreshing the page and clicking on the vote and put unnecessary load on the server. How to avoid that by doing some sort of client-side thing or something?
I am using ASP.NET MVC, so session variables are out of question.
Am I being over-concerned by this?
If voting happens only from logged in (known) members then you shouldn't have any problem.
If, on the other hand, everyone can vote then you need to store all user vote events:
timestamp
poll
poll_vote
ip
user agent
user uniqueness cookie
So you'll need a random hash sent out as cookie. This will ensure that you don't accept another vote for the same poll from the same person.
If the user deletes his cookies you fallback to plan B, where you don't allow more than (say) 10 votes from the same IP and user agent combination for 24 hours.
The system is not perfect since users can change IPs and (more easily) user agents. You'd need advanced pattern detection algorithms to detect suspicious votes. The good thing about storing all user vote events is that you can process these later on using a scheduler, or outsource the votes to someone else who can process them for you.
Good luck
Refreshing is not a problem
If you're doing all this voting using Ajax, refreshing a page won't do anything except load the page using GET.
If you're not using Ajax you should make sure you call RedirectToAction/RedirectToRoute action result, that would as well help you avoid refresh problems.
How do you recognise users
If you use some sort of user authentication this re-voting is not a problem. But if your users are plain anonymous, you should store IP address with your votes. This is how things are usually done. This makes it possible to avoid session variables as well. But you have to be aware of this technique because it's not 100% perfect.
Cookies?
You could of course also use absolute expiration cookies. They'd expire in an day. Advanced users would of course be able to avoid your voting restrictions, but they would be able to avoid other ways as well. Sessions BTW are also based on cookies anyway.
Combination
But when you'd like to make you system as great as possible, you'll probably use a combination of the above.
The best way would be to track who voted for what and when on the server (probably storing it in a database). In order to do this you must use an authentication system on your site (probably forms authentication) to identify users. So every time someone tries to vote you check first in your data storage if he already voted and when and decide whether to validate the vote or not. This is the most reliable way.
If your site is anonymous (no authentication required to vote) then you could store a persistent cookie on the client computer that will last for 24 hours and indicate that a vote has already been cast from this computer. Remember though that cookies might be disabled, removed and are not a reliable way to identify a given user.
I am using ASP.NET MVC, so session
variables are out of question.
Any reason for that? Sessions are perfectly fine in ASP.NET MVC applications. It is in your case that they won't work because if the user closes the browser he will lose the session.
Obviously, he would not be able to
cast vote, because of my algorithm,
but the person would still end up
succeeding in making call to the
server. So if he really wanted, he
would keep refreshing the page and
clicking on the vote and put
unnecessary load on the server
Automated bots could also put unnecessary load to your server which is much more important than a single user clicking on F5.
If you just want to ensure the user can only vote once on an article then you just need to store a Set (i.e. HashSet) of all article id's that they've already voted on, then just check before allowing the vote.
If you still wanted a 24hr limit then you need to store a Dictionary<articleId,DateTime> then you can check if he has already voted for that article and if he has when it was.