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.
Related
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.
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).
I am planning to create a online examination sytem in PHP. What steps could I take to restore old session, if user has accidentally closed the window?
Suppose he has already answered 49 questions out of 50 and suddenly there is power cut off (and there is no UPS) or he accidentally closes the window (even by mistake, if he clicks yes on javascript's prompt on window.unload event) and then reopens the browser, everything is lost. What could I possibly do to prevent this?
Thanks in advance :)
You would need to do one of two things:
Persist the current state on the user machine - this would have to be done via a cookie.
Persist the current state on the server.
The second option is probably more reliable, it does require that you are in constant contact with the server. It would also allow the session to resume on another machine.
The first option would probably be easier to implement.
Offer a login system where you store the progress tied to the user login, or simply use cookies that do not expire upon closing the browser (i.e. set an expiry date far in the future).
You can store the session parameters in cookie which expires after 30 day e.g.
You could save their state every time they go to the next question - if it's saved in a session, you could serialize the session and save it in the DB, related to their account.
If they open up the browser again, you can then load up the saved session, unserialize it, and continue off where they left it.
Storing the session id as a cookie with a long expire time will solve the problem but will introduce a new issue: on public or shared machines, users will have to explicitly log out (i.e. destroy the session) otherwise everyone that access the site after they quit will continue their session.
Another solution is to bind 'exam sessions' to the user, persist them on the database and continue the session if an user with a pending exam logs in. Obviously this require a bit of coding :-)
continuously save the page state into a cookie (e.g. on every form change - thus you have the state of the current page);
on submit, save the state into session (or even into database of unfinished forms) and clear it from cookie (thus you have the overall state of the exam stored server-side, so you can clear it from the cookie).
When finished, clear both cookie and session.
Of course, if there's a power outage, the cookie may not have been flushed to disk yet, but otherwise (especially if you have multiple questions on one page), the user will lose less state than if you only saved on submit.
I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.
Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.
How do you deal with this?
A few ideas that I have are:
After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.
Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)
Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.
For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).
Are there other better methods?
--
Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.
I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.
Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.
I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.
Regards
I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).
this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.
Normally you should do 2), but you don't like it.
maybe you can use sessions stored in db.
when a user change his name, put into all sessions from that user the information "refresh userdata".
on the next request the userdata is reloaded again into the session and is cached there.
this can be done be reusing your loaduserdata function which called at login.
php session_set_save_handler() - also read comments
php session_decode() - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.
[edit]
don't forget:
when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.