Recently I have opened a question here about a problem I was while modify session values for other user's session.
Link for the question: PHP Session: How to Edit Other user's Session / Editting Session file
Situation Description:I was trying to directly edit the file stored in the server for each user. But due to protections and file lock, the best I could was to end the session when it needed any force update, by using a class that implements the SessionHandlerInterface.
Well, right now, i wish to know what other type of ways i could store values, rather than session-cookies or parameters on the URL (Database doesn't count). Is there a way to have it gathered in memory ?
Example 1: I user enter the System and changes the System language. I save the current language on the Session.
Example 2: A user enables the mobile version of the site by a implemented function, and it's stored in it's session that the site is mobile.
Example 3: A user is logged in, and it's object is stored in the session.
Saving temporary date in sessions is ok, just keep in mind it won't be there next time. Same goes with cookies, but with cookies you also have to consider the fact that user can alter them.
Loading data on login and storing it in session is not bad idea especially when you have to consider performance, there's really no reason to pull all data from database on every page load unless you just wanna kill MySQL server (once you have more data and concurrent users).
Related
I've been reading up on (mysql) triggers the last few days... specifically what I'm trying to do is figure out a good methodology for updating a user's information.
The case use for this is related to a user management system:
Take for instance a admin user updating a regular user to a manager, this user type change would then enable|disable software features on the interface.
Problem:
You won't know about this user type change unless you query the database and reset say for example the $_SESSION['user']['type'] variable, and or the user logs-in|out of the system.
Question: Is there any good methodologies to solve this headache?
I don't think mysql triggers would be ideal for this. Why? Because you will most probably end up with part of logic in php and part in mysql. It's a good thing to stay with one technology because it will be easier to maintain/debug code for you and your colleagues later.
So in your case, if you want the change of user role would take immediate action, you would have to either load user role on each script run or log out user using some flag in database that would signal that his session is not valid anymore (or you could implement your own session_set_save_handler that would save session somewhere in file where you could delete it to log out user).
It depends on your needs which solution would better fits your case.
If your roles logic is complicated and it consists of multiple roles assigned to one user as well as extra permissions assignments/excludes per user it may be better to do this check once on user log in and then just remember the result using session.
If checking for permissions on each script run isn't an issue, you can do it. But be aware, for security reasons, it may be a good practice to force user to log in again.
If the user log out could cause lose of work, you should let user log out itself and apply new permissions after next log in (you can show user a message that new permissions are awaiting log in to take effect).
So it really depends on your needs to choose if it's better to log out user, give him new permissions right away or wait until next log in.
Question: Is there any good methodologies to solve this headache?
Find good reasons not to do it!
While this might sound like a joke, i am completely serious. You have to consider:
What is the value of that feature?
Is it worth the headache cost?
What are the risks of that feature (incomplete work / system consistency)?
Do you have to change the system core?
Would you have to revalidate the system?
Are there other really great features (system improvements) waiting to be implemented?
Someone who doesn't feel comfortable answering these questions doesn't really need that feature.
Find simple alternatives:
Call the user and ask to log out.
Notify the user per email.
Provide a button for email notification.
Send email notification automatically after changing permissions.
This is no laziness. Just focus on real value.
One alternative would be to do ajax requests, with some time interval, that will update your user $_SESSION.
If you have any changes in your 'type', you can do whatever you want, like force user do re-login your application, or do nothing but update $_SESSION information.
Of course, you need to know if you really need to get this information before user logout and login next time, with updated profile.
I think storing your session into caching mechanism like Redis would give you added advantage. It is light weighted than storing session data in database. You can create clusters very easily. Click here to see sample implementation.
So once a user "type" changes, you can load the redis data cache and update it as per your wish.
I think the safest way to do this, and the one that I would choose is the "headache" way.
'regular' user A logs in and opens session A1.
'admin' user upgrades A to a 'manager'.
For now, session A1 is a valid session, but it will not grant the user 'manager' privileges.
When user A logs out and logs back into session A2, this session will now grant the user all the privileges of a 'manager, having looked up the current 'type' from the database.
Alternative that may be slightly expensive depending on your application:
Every time a user presents a session token, use the database to check against the validity of the session. If that session has invalid info (ie. the 'type' no longer matches) then force the user to log back in again.
Adding another alternative:
Don't use a MYSQL trigger, when the application caller (the admin) updates User A's 'type', it also makes a call to wherever you're caching the sessions and either (a) updates the session (inadvisable*) or (b) renders the session invalid and forces the user to log in again.
*Note that all of these solutions require the user to re-enter their credentials after they have new-found 'manager' power before they have access to the 'manager stuff'. I think this is a safer practice than updating the session without any authentication.
My recommended methodology would be to store the type of each user in the database. The problems that would arise if you decided to store the type as a session variable would be (among others):
Once the session expires, this information would be lost. Usually sessions last 30 minutes, though you could modify this to be as long as you want. However if you create a session that lasts 1 month, then anyone who has access to that users computer would be logged into the users account without needing to use any password.
You would be unable to use powerful and advances queries offered by databases (like MySQL for instance which uses SQL). If you store your information in sessions, sure you can find a way to look up each users information 1 by 1, but why reinvent the wheel? It is not easy developing a database structure from scratch, so I wouldn't recommend doing it.
Regarding your concerns on accessing a database once the information has been updated, I wouldn't say this information is as concerning as you might believe it to be. Lets imagine the following examples:
1)
If a user for instance is a manager currently and loads a website where he can do powerful actions, and right afterwards he is demoted to being a normal user, then having this information in the database would work perfectly. If the user tries to use his powers (that are no longer his), he would click a button that would send an a request to the database to confirm his type. Database queries are very fast, so speed is not an issue. I would be more concerned of the speed it takes for you to obtain information from a session variable than from the database.
2)
If the user was on a page while he was a normal user, and while on the page he became a manager, then he would be able to exercise his powers after refreshing the page. I mean if you used sessions and you wanted to have the page obtain the information automatically with something like AJAX and then update his options on the page, that would consume much more server power than a simple refresh.
To give a simple SELECT * FROM myTable WHERE id = 4 can take as little as 1 millisecond to be executed on a database. Databases have been especially designed for their speed which is why they are prefered
HOWEVER, maybe you don't have access to a database and that is why you are searching for an alternative? Well you are in luck! MySQLi is a database which only uses a file to store the information. It was especially designed for users that don't have much resources, and has many of the capabilities as MySQL would have.
Since every user has a role or type it means that the ability of viewing or editing content in your application is solidly connected to this factor. This means that the 2 basic things that your session variables should have are userID and userType which you should also store in your database
These pieces of information can be passed to $_SESSION['user'] for example as a small array where your array key can be the userID and the userType the value.
$_SESSION['user']=array($userID => $userType);
Once a user login your initial values are stored to session. In order for your application to know what userA can view or edit in your application, you basically run a comparison in your script against the userType that userA has. But to achieve what you want you basically need to re-fetch the piece of information in the beginning of every VIEW/PAGE of your application. If new userType has been assigned to userA simply show a message that he/she will log out automatically in 15 seconds (give time to read the message itself) in order for the changes to take effect. While your user sees this message you take the current session data he/she may have and save it in database, since some session variables might be (or not) available in a upgrade or downgrade of userType. By placing the comparison of the userType in the beginning of each VIEW/PAGE of your application you save yourself of the headache that a user can loose data.
If your scripts use $_SESSION['user']['type'] to know about the user's privileges, I would just change its value.
Or perhaps I didn't understand the issue ?
We want to use sessions instead of cookies for keeping track of a few things. However, when I close my browser, and I reopen a page to echo a session var, it doesn't exist (which is how it is suppose to be). Is it possible to prevent this from happening with some magic or anything?
This is not a duplicate question, all I see are people wanting to destroy sessions, I want to do the opposite and retain the session for as long as possible.
Any knowledge would be appreciated.
The right way of doing this is with a database, you can mimic or control php sessions and store them in a database instead of in a file ( as normal ). Then once you have control of the data you can base renewing session via the ip address or better yet by login.
So say a user logs in and then you need to store some data, you store that in the session but php will store it in your database table ( when configured correctly ). Latter the user comes back, initially any visitor would get a fresh session, however once they login you would be able to retrieve the past session they had. You generally don't have much control on if or when a client will delete expired cookies.
This topic is too extensive to put just a few pieces of example code but I did find this small article on the topic.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
The guts of it is to use this function, session_set_save_handler
http://php.net/manual/en/function.session-set-save-handler.php
Once you have control of the data you can do whatever you want, however I would caution you about relying only on the IP address and it would be preferable to use a login system for something like this to prevent serving the session up to the wrong visitor.
You cannot reliably control what happens on the client side, even using a separate cookie would not be reliable and would have the disadvantage of storing data on the client where it could be accessed instead of keeping it on your server. Sessions are controlled by cookies but the data in them remains on your server, the cookie just identifies the client.
As a side note, I personally dislike using sessions at all. It may be possible to store what you need in the url, then it can be bookmarked. The classic example would be input for a search form ( via $_GET ) or for paging purposes. There is nothing wrong with doing this if it's not secure data. The problem with sessions is if the data is for a page such as my "classic example" or for paging you get only one session, so you would only be able to have one set of search data at a time, in the url you could have several sets of search data open at once. That said it does largely depend on what you need to save or persist.
Reset the session cookie manually.
$lifetime=60*60; // duration in seconds
session_start();
setcookie(session_name(),session_id(),time()+$lifetime);
You can use session.gc_maxlifetime and session_set_cookie_params, i.e.:
// server should keep session data for AT LEAST 1 Year
ini_set('session.gc_maxlifetime', 3600 * 24 * 365);
// each client should remember their session id for EXACTLY 1 Year
session_set_cookie_params(3600 * 24 * 365);
session_start();
Note:
You can also change the session options globally by editing php.ini -
Session configuration options
PHP sessions use session cookies. Browsers have their own ways of dealing with them but they all consider them to be trash if you close the browser.
Session cookies are not and can not be made persistent. If you need persistent cookies, just use a regular cookie to save a user identification code that your server would recognize, and save their session information in a database or flat file indexed on that id code.
Note that accumulating sessions on the server progressively causes important performance and security concerns.
Note on other answers: All of them mention ways to extend the session cookie expiration which will not overcome the regular behavior when you close your browser window.
I know there are hundreds of these questions but what I am asking however is slightly different.
When the user logs in I would like to get all their data from each table in a database and store it in a session variable (obviously not sensative data such as encrypted password/salts etc basically data that would be useless or have no value to a hacker!!), and whilst the user uses the website the relevant data stored in the session will be used as opposed to accessing the database everytime. Moreover when the data is changed or added this will be written or added to the session file, and upon a major action such as "saving" or "loggin out" the new/changed data will be written to the database.
The reason I wish to do this is simply for efficieny, I want my application to not only be fast but less resource consuming. I am no expert on either which may explain why my idea makes no differnece or is more resource intensive.
If there is an alternative to my solution please let me know or if there is something to improve on my solution I will be glad to hear it.
Thank you.
My application is using PHP and mysql.
If any of these don't apply to your app, then please ignore. In general, I'm against using sessions as caches (especially if anything in the session is going to be written back to the DB). Here's why.
Editing the session requires a request from the user. Editing a php session outside of the request-response cycle is very difficult. So if a user Alice makes a change which affects Bob, you have no way to dirty Bob's cache
You can't assume users will log out. They may just leave so you have to deal with saving info if the session times out. Again, this is difficult outside of the request-response cycle and you can't exactly leave session files lying around forever until the user comes back (php will gc them by default)
If the user requires authentication, you're storing private information in the session. Some users may not be happy about that. More importantly, a hacker could imploy that private information to conduct a social engineering attack against the end-user.
Mallory (a hacker) might not be able to use the information you put in the session, but she can poison it (ie. cache poisoning), thereby causing all sorts of problems when you write your cache to your permanent storage. Sessions are easier to poison then something like redis or memcache.
TL;DR Lots of considerations when using a session cache. My recommendation is redis/memcache.
You can also go for local-storage in HTML5, check The Guide and THE PAST, PRESENT & FUTURE OF LOCAL STORAGE FOR WEB APPLICATIONS
Local Storage in HTML5 actually uses your browsers sqlite database that works as cookies but it stores data permanently to your browser
unless someone by force remove the data from the browser finding the data files
Or if someone remove/uninstall browser completely,
or if someone uses the application in private/incognito mode of the browser,
What you need to do
Copy the schema for required tables and for required columns and update data at a regular interval
you dont have to worry about user's state, you only have to update the complete data from the localStorage to mysql Server (and from the mysql server to localStorage if required) every time user backs to your application and keep updating the data at regular interval
Now this is turning out to be more of localStorage but I think this is one of the best solution available for me.
redis is a good solution if it is available for you (sometimes developers can't install external modules for some reason) what I would do is either go with your Session approach but with encoded/encrypted and serialized data. Or, which I really prefer is to use HTML5 data properties such as:
<someElement id="someId" data-x="HiX" data-y="Hi-Y" />
which BTW works fine with all browsers even with IE6 but with some tweaks, specially if your application uses jquery and ajax. this would really be handful.
You need to use Memcache for this kind of work. To solve the problem of keeping the updated data everywhere you can create functions for fetching the data, for example when the user logs in you, authenticate the user and after that insert all the user data into the memcache with unique keys like :-
USER_ID_USERNAME for user's username
USER_ID_NAME for user's name
etc...
Now create some more functions to fetch all this data whenever you need it. For ex
function getName($user_id){
if(Memcache::get($user_id."_name"){
return Memcache::get($user_id."_name");
} else {
//Call another function which will fetch the data from the DB and store it in the cache
}
}
You will need to create functions to fetch every kind of data related to the user. And as you said you want to update this data on some major event. You can try updating the data using CRON or something like that, because as tazer84 mentioned users may never log out.
I also use what the OP described to avoid calls to db. For example, when a user logs-in, i have a "welcome-tip" on their control panel like
Welcome, <USERS NAME HERE>
If i stored only his user_id on $_SESSION then in every pageview i would have to retrieve his information from the database just to have his name available, like SELECT user_name FROM users WHERE user_id = $_SESSION['user']['user_id'] So to avoid this, i store some of his information in $_SESSION.
Be careful! When there is a change on data, you must modify the data in db and if successfull also modify the $_SESSION.
In my example, when a user edits his name (which i also store in $_SESSION so i can use it to welcome-tip), i do something like:
If (UpdateCurrentUserData($new_data)) // this is the function that modifies the db
{
$_SESSION['user']['user_name']=$new_data['user_name']; // update session also!
}
Attention to:
session.gc_maxlifetime in your php.ini
This value says how much time the $_SESSION is protected from being erased by the garbage collector (the file that exists on your disk in which the $_SESSION data are stored)
If you set this very low, users may start getting logged-out unexpectedly if they are idle more than this amount of time because garbage collector will delete their session file too quickly
if you set this very high, you may end up with lots of unused $_SESSION files of users that have left your website a long time ago.
also i must add that gc_maxlifetime works together with session.gc_probability where in general you need lower probability for high-traffic websites and bigger probability for lower traffic since for each pageview there is a session.gc_probability that garbage collector will be activated.
A nice more detailed explanation here http://www.appnovation.com/blog/session-garbage-collection-php
I know this sounds stupid but ....
If ur data is not sensitive the best way to make it accessible faster is to store it in hidden variables inside the forms itself. You can save comma separated or values in an array.
I was wondering if using a SESSION variable to pass data from one PHP page to another is efficient. I ask this because I thought that SESSIONS were only used to keep the user logged in to a website, and as an alternative to cookies. Would it not be better to pass data (non-sensitive) from one page to another via a URI such as members.php?name=Joe&age=28?
A PHP session writes a cookie to your browser and then stores the data associated with that session on disk; its about as expensive as an include() to read it back in on the next page load, which is to say completely trivial.
Additionally, the user can't change session data unless you create a mechanism which allows them to; they can mess with the query string easily.
Short answer: Yes, its efficient.
Sessions are useful for lots of things, not just login information. They're great for holding status messages during a POST/redirect/GET cycle or anything else that keeps track of the state of the user's session (hence the name) - but only the current session, not long-term permanent configuration options.
As far as efficiency goes, you need to remember that anything in the session needs to be serialized & unserialized on every page load. Storing a name and age wouldn't add much. Adding a megabyte of image upload would probably be bad.
More important than the efficiency consideration is to remember that session data is only temporarily persistent. If you want to always know that Joe is 28, it should go in the database. If it's only useful on a single page load, it should probably stay in the URL or be POSTed. If you're interested in remembering it for a few minutes, the session might be the place to put it.
Depends on what you're doing. If that page requires that information to function properly and is not behind a login then passing in a query string is the way to go (e.g. search results, product pages). If it is behind a login then using a session would allow you to keep your URLs clean and also make it difficult for users to abuse the page (e.g. swap out data in the query string).
Yes, you can store data and message in SESSION and it is accessible from any page. But remember, SESSION uses browser support to store data. They can be deleted manually by the user
I've got a php application and I'm saving the session variables for the user using $_SESSION itself. Is there any particular advantage of storing it in a database?
I'm looking for a reliable / well-researched article which talks more about this. I havent been able to locate anything yet.
The advantage you have of storing it in a database is that the data exists as long as you want it to exist.
Your browser will destroy the session according to how it is setup, which makes it a bit unreliable. I can't however find an article on this yet but this is what I use as a convention for a situation like this.
Any data that needs to be stored long term, like user details and activity I store in a database. Any data that is only relevant to the current workspace, like logging into a site and posting a few comments etc. can be stored in the session. For instance I store user authentication details in a session to constantly check whether the user is logged in or not and whether to redirect him/her to the correct page.
This works wonders when checking access rights throughout your application.
For me its much safer to store user details in a database because it cannot be publically accessed like the $_SESSION.
Please disagree with me if you want to though.
I would say storing in database is better.Because
When you are hosting your site with a shared host
PHP uses the same path for storing sessions for all the users,somewhere that is not in your folders.
You can track the users and their status easily.
For application that are running on multiple servers, you can store
all the session data in one database.
This article may help.
Well this is a question for the ages. Personally from what I have learned in my time. Unless your site starts booming on a massively large scale where you need to start using multiple servers for various aspects of the system such as load balancing where you have many mirror systems running. Or need to improve performance a little for an over populated system the benefits of using DB related sessions or File based sessions really isn't any different.. Grant it I could be wrong this is merely my own personal perception off my own experiences. Just like you Ive never really found any articles, posts, other that really put either to the test side by side hell I don't even think I have found anything that really puts either to the test stand alone for that matter. Personally I just go with what ever the need is (or desire of my client) usually I just stick to native sessions file based.
I hear they can be spoofed, but have seen no proof to that notion to date. So other than that potential I stick with file based. Unless I am using a system like code igniter then sessions seem to handle better DB driven with it rather than not.
At some point in time you're going to have to store something in a session. Whether it's all the session variables or just the ID of a row in a sessions table. That being the case it would be fairly easy to alter the ID stored in a badly encrypted session and hijack a different session.
Consider this:
Full Session Option. This has the User ID, Username and an encrypted and hashed password stored so that every time a page is called it verifies my login. To hijack someone else's session I'd have to know their User ID, Username and Password Hash and be able to overcome the sessions inherent encryption.
Session + DB Option. This just has a Session ID stored that references a row in a database. All I have to do to change the session I want is to break the encryption on the session and say add one to the Session ID. I'd then be authenticated as the user that logged in after me.
You could store login details in a session and then any none login related data in a session table if you have a lot of extra information but then again you might as well just remove the need for an extra table and extract the data from whatever relevant tables you need.
From my short experience, you should store in $_SESSION only data that you will NOT need to be refreshed in all sessions opened by a unique user in different devices.
(mobile/desktop/etc.)
In other words, data that you are sure will never change like a userID.
For example, I had stored the user profile picture path into
$_SESSION and it led to a strange User Experience. When changing the
profile picture in a desktop, it did not refresh the profile picture
for the user on his mobile. Other users saw the new picture though.
Indeed, the path was refreshed into the DB but not in the $_SESSION.
Login-out and Login-in would not change anything.
Remember that the default behavior is that $_SESSION passed with cookie will be different for each browser even if this is the same user logged in. You will have to do a session_destroy() to avoid being stuck with old data.
Very temporary data may be stored in $_SESSION as well I guess.
NB: the basic need of global session, out of these arguments, is to have variables available globally