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).
Related
I am sure someone has run across this issue before, I just haven't been able to find anything on it anywhere. Anyway here is the scenario.
I have a PHP website that a user will login, then their account id is set as a session variable, then once they are in it basically acts as a single page app. The session account id is for tracking their activities as they do different things throughout the app.
The site will be accessed primarily on mobile devices. I have PHP that sets the session timeout length, then using JS, gives them a popup warning a couple minutes before the timeout ends. Then after the end of the timeout, using a meta refresh, it redirects them back to the login page.
On a desktop, this all works like it is supposed to. On mobile, it is behaving differently. On a mobile device, a user may login, do some stuff on a page, then without logging out, put their phone in their pocket and not come back to it for a couple hours. When they open up the browser it keeps them on the page they were on, but the JS was obviously not running during the time their phone was sleeping, or whatever else they were doing in the interim. The meta refresh as well also does not work as expected, but the session is still timed out. So when they open the app back up, and try to do stuff, I am getting errors in the DB saying that id cannot be empty.
I can use ajax to check if their session still exists on every click of a button, but for speed of the app I would prefer not to do that.
Has anyone else ran into this and found a solution for automatically logging out people on single page apps viewed on a mobile device?
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.
In my login code on my website, if the password & username are correct, I set a cookie to keep the user logged in.
I just heard from a user that he doesn't accept cookies automatically through his browser, and that that prevents him from logging in. That rhe cookie is not set.
Is there an easy way to counter that?
Tell me if you need the code I use.
It is possible to get this to work but often a real pain if you're using complex javascript/ajax.
In short, instead of storing the session id in a cookie, you embed it at the end of every link.
so
http://example.com/somepage.php
becomes
http://example.com/somepage.php?SessionId=ABC123
Unfortunately, while PHP can do this for you in some cases, it doesn't help with links you build yourself in javascript - and it only takes clicking a single link without the id to effectively log the user out
See this page for more information
As mentioned by Quentin in the comments, if you're not using a cookie to identify the browser which created the session, it's possible that sharing a link would share the session. This could be mitigated but not prevented by checking IP address/user agent but this would likely fail in large corporate environments with NAT and standard browsers
Currently working on some other aspects of my project, but while I do so I was hoping to get some information on a problem I will be working on very shortly. After a very brief search didn't turn up anything immediately I thought I would leave the question here to see if anyone else has cleverly solved this issue.
Heres the problem:
We a developing a very typical CMS yet with some higher profile clients that require higher security then most CMS' that handle personal blogs, therefore the user sessions must expire to help in preventing session hijacking. Currently set at 20 minutes, but we would like to set it to more to 10 minutes of inactivity. The problem would come up if the client is say, writing a big article, or taking a looong time to fill out a form, when they click to save, if their session has expired they will loose all their data. That would make for some very nasty emails I'm sure!
Has anyone come up with a nice solution to this? My thoughts were to have a javascript automaticlly save form data to the users browser (possibly as a cookie) every few minutes, and when the users session expires, after they log in and go back to the page, the javascript would fill out the form again. After a successful POST the javascript would clear itself.
Thoughts from the SO community?
jsper or another library like it would be a good bet; it allows you to save data in the browser and supports all browsers (back to IE6) using localStorage, cookies, data attributes, etc.
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 :(