Using Symfony 2.0 and FOSUserBundle, I need to know how to restrict the access to make it unique.
This is what I mean:
User X accesses to my system creating a session through login/password
With that session still valid (not having closed the session, etc...), the same user X tries to access from a different computer or location.
In that case, I need the system to avoid its second access with some kind of message: "that user has a valid session from another computer".
Is that possible?
It would be possible and trustable only if you could find a secure way to know when the user session has destroyed or he has logged out from the other computer. As it can occurs without explicit action from the user (i.e. he closed the browser and the session timed out), I wouldn't rely on it. Of course you could always try to find some workaround (i.e. predicate session expiration time and track user logging out) but it still would not be 100% secure. Thinks about cases where new accesses will be denied because a session is still open on another browser without people in front of it.
On the other hand, you can do it the other way (when new user logs in, the other logs out) using Voters and some hints found in Allow one session only at a time.
Correct me if I am wrong, but I think there is finally no way to do what I am trying to since Chrome (and I think FF too) save the exact cookie and are able to restore the session skiping all LoginHandler methods.
Let me explain myself.
Right, I was about (and actually I did) to implement the solution described in your answers and comments:
User X enters the web site with his login/password using Safari (for example)
The login datetime is stored both in table User in the database and in session
Without logging out, the same User X opens a different browser (Chrome, for example)
The new login datetime is updated in database and in Firefox session
The user gets back to Safari and tries to refresh the page
He gets an exception as the datetime doesn't coincide with the one stored in session
Well... great so far, as it seems to solve the problem.
And here comes the big deal: as described here and here, Chrome is not deleting properly the session cookies. So when user doesn't logs out and just close the browser, anytime he or she comes back to Chrome, the session is automatically restored without passing through a login handler, login method or anything around.
This causes that "magical" datetime key not to be saved both in database and session and, as a result, put a stick in the wheel of letting just one session as a time, what was the original plan.
Any more light on the issue??
I want to cry :(
Related
I have read many answers on stackoverflow, but none of them could answer my question.
Let's consider a case, where a teacher and the student use the same computer. The teacher uses it to upload marks and the student use the computer to browse the marks. Now, the cookies of the teacher are stored and accessible. The student can easily forge the cookies and present himself as a teacher to the system and create havoc.
What approach should I take to disable this? Is this only possible via sessions? Or there exists a possibility with cookies as well.
The main two suggestions I would have are:
Delete the entire session right before the user logs out or logs in. A new session should always be started when authorization level changes.
Only accept sessions ids you generate. By default PHP will accept and start a new session for any value of the session id you send it. If you receive a session id you haven't seen before, discard it and send the user a new one.
If it's not necessary to have the browser remeber the cookie between browser sessions (eg a login can be 'forgotten' if the browser window is closed), then you could NOT set the expiry date on the cookie which makes it memory-resident only.
When the user closes the web broswer, the cookie is forgotten (standard browser behaviour) so there's no link to the old session, and a new login must be provided. The old session becomes "orphaned" and (assuming you have a 'expire through inactivity' process) will be expired eventually.
If you need the browser to remember the last user even if the window was closed, then a short-but-appropriate timeout is needed - destroy the session making the cookie useless after x minutes/hours inactivity (whatever is appropriate).
So I am working on a site that requires a login against an MySQL database with "remember me" functionality. I got that fine (based off of Jaspan's page). What I am a little fuzzy on is the use of sessions to track user movement. I'm not worried about their history on the site. I've looked around on the interwebs and especially SO, but I haven't really found what I'm looking for. Perhaps I'm just not using the right keywords to search. Anyway... as I said, I have the actual login process, and a cookie is set up with the triplet for the "remember me" functionality. But how do I track the authenticated status while the user is browsing the website? The logged-in user should be able to browse the secure area of the website, or the scripts should output special data, without the website having to check the "remember me" triplet against the database every page load. I thought to do something like $_SESSION['authed']==true, and every page load would check the session value, but I suspect that isn't a very secure way to go about this. I have observed that if I set $_SESSION['authed']==true, close the browser, open the browser, and go to the site again, it still says authed=true. Now, I DO understand that the session variables are stored on the webserver, not in the browser's cache. However, I can't see the big picture enough to know the right way to go about this.
I thought to do something like $_SESSION['authed']==true, and every page load would check the session value
Yes, that's what you do.
but I suspect that isn't a very secure way to go about this
It's perfectly fine. You establish a session, which means you send a unique cookie to the user. That is your security. The fact that you have a session at all is your security. Then you simply record the fact whether the user is "logged in" or not in that session.
I have observed that if I set $_SESSION['authed']==true, close the browser, open the browser, and go to the site again, it still says authed=true.
Yes, cookies don't necessarily expire when the browser is closed. Each cookie has a specified expiration time, they can persist however long you want. Even cookies without an expiration time aren't necessarily immediately discarded when the browser is closed. That may have been the default behaviour of browsers a few years ago, but isn't necessarily true anymore.
Using Symfony2 and FOSUserBundle, I am not getting the expected behavior on the following implementation.
To begin, know that Continue where I left off option in Chrome restores completely the user session independently of having checked some "Remember me" or something like that. Therefor,it saves a cookie with all the information of the session.
What I am trying to do is to avoid the creation of a session from the cookie stored through that Continue where I left off option on Chrome.
Or, if I cannot avoid the creation of the session, at least try to know that the session comes from that completely transparent way.
I have found this in Symfony2 documentation (specifically here):
In some cases, however, you may want to force the user to actually re-authenticate before accessing certain resources. For example, you might allow "remember me" users to see basic account information, but then require them to actually re-authenticate before modifying that information.
The security component provides an easy way to do this. In addition to roles explicitly assigned to them, users are automatically given one of the following roles depending on how they are authenticated:
IS_AUTHENTICATED_ANONYMOUSLY - automatically assigned to a user who is in a firewall protected part of the site but who has not actually logged in. This is only possible if anonymous access has been allowed.
IS_AUTHENTICATED_REMEMBERED - automatically assigned to a user who was authenticated via a remember me cookie.
IS_AUTHENTICATED_FULLY - automatically assigned to a user that has provided their login details during the current session.
So, if I don't get it wrong, a user that transparently logs in as a result of the Copntinue where I left off option, should have the IS_AUTHENTICATED_REMEMBERED.
Well, the reality is that it is not thus. The reality is that the granting is IS_AUTHENTICATED_FULLY.
Has anyone passed through this?
Any idea on all this?
Thanks
Sessions are handled server side. Depending on your server's configuration for sessions lifetime, you can close your browser and re-open it without losing the session. This has nothing to do with the Continue where I left off option of Google Chrome.
The granting is IS_AUTHENTICATED_FULLY because the session is still active on the server and not because of the Google Chrome option.
Simple example use case. Let's say we set a 5 minutes session lifetime.
Without the remember me option :
I log in : a session is created on the server.
I close the browser.
I come back 10 minutes later : session has expired therefore I have to provide my credentials.
With the remember option :
I log in : a session is created on the server AND a cookie is created on my browser saying hey I'm connected.
I close the browser.
I come back 10 minutes later : session has expired BUT as the result of the cookie saying hey I'm connected, a new session will be automatically created. Therefore I will not have to provide my credentials again.
In both case if you come back within the first 5 minutes you will be automatically logged in because the server still handle a session for your browser.
I have a PHP site that works great....as long as there are no network disruptions. im having problems with users, especially on iPad's and laptops, that log in, and work within the site without submitting any data for a prolonged length of time (maybe an hour or so). They type a bunch of notes in, and when they submit they are sent to the logon screen and what they worked on for that hour is lost. I'm getting used to dirty looks...
My research as shown that maybe using cookies will help the issue. security is not a huge concern, so storing usernames and hashed password within cookies is not a big threat. but i never worked with cookies and don't know where to really begin. my objective is to have any user be able to log in, start typing in a text area, move throughout the building, maybe dropping their internet connection and picking it back up, and be able to submit the form after with no errors. any ideas? thanks in advance...
Sounds like your session is simply expiring, nothing to do with changing internet connection or Wifi AP.
Change the default PHP session expiry with PHP, or change the php.ini setting:
ini_set("session.cookie_lifetime","3600"); //an hour
The default session handler works by setting a session ID cookie on the client. With each page request, the session ID will be sent. If the session expires, the cookie will be deleted and thus the client will be shown the login screen.
That's assuming you are using the default PHP session handler (you didn't say). If that's not the problem, then it would point to a problem in your code, for example if you are trying to prevent session hijacking by comparing IP addresses (which will change as the user moves from AP to AP).
Apologies if this question is already posted. I didn't find the answer i was looking for when searching through the related questions.
I have a login system I've just created that works with Facebook. Once the user logs in with their Facebook info and then I create profile in my database for them. I start a session upon successful login and store the user's id in that session. This setup so far has worked fine, but I've recently noticed if I try to login to the site on another browser (1xChrome, 1xIE, so on...) at the same time it wont let me. How can I fix this problem? I would like the user to be able to not only log into multiple browsers on the same computer at the same time, but if they stay logged in at home be able to still log in from another computer.
Any help is greatly appreciated!
Thanks!
EDIT: Yes I'm interested in allowing user's to log into multiple browsers as in 1xChrome, 1xIE, 1xSafari, etc. I should've been more clear. sorry.
You may want to do some more research into cookies.
Your users should not be able to use multiple instances of the same browser (for example, 4 Internet Explorer windows) to log in.
Your users SHOULD be able to use different browsers (ie 1 x IE, 1 x Firefox, 1 x Chrome or any of the above browsers + 1 with Private Browsing/Incognito/etc enabled).
The reason for this is because the cookie storage is different. You could technically use different Firefox profiles, too, I think...
... but to get back to your question - you might want to learn more about Cookies and their function in sessions.
The session should not be terminated, unless you do a check and terminate it yourself. An issue could be the actual facebook login. If facebook does not allow multiple logins(i think it does not), your first browser session will be getting an expired session( if you check on the facebook login status ), and this could cause your script to refresh the state of the first client (again, if you handle it like that).