One thing I've started doing more often recently is retrieving some data at the beginning of a task and storing it in a $_SESSION['myDataForTheTask'].
Now it seems very convenient to do so but I don't know anything about performance, security risks or similar, using this approach. Is it something which is regularly done by programmers with more expertise or is it more of an amateur thing to do?
For example:
if (!isset($_SESSION['dataentry']))
{
$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=" . mysql_real_escape_string($_GET['wave_id']);
$result_taskinfo = $db->query($query_taskinfo);
$row_taskinfo = $result_taskinfo->fetch_row();
$dataentry = array("pcode" => $row_taskinfo[0], "modules" => $row_taskinfo[1], "data_id" => 0, "wavenum" => $row_taskinfo[2], "prequest" => FALSE, "highlight" => array());
$_SESSION['dataentry'] = $dataentry;
}
I use the session variable all the time to store information for users. I haven't seen any issues with performance. The session data is pulled based on the cookie (or PHPSESSID if you have cookies turned off). I don't see it being any more of a security risk than any other cookie based authentication, and probably more secure than storing the actual data in the users cookie.
Just to let you know though, you do have a security issue with your SQL statement:
You should NEVER, I REPEAT NEVER, take user provided data and use it to run a SQL statement without first sanitizing it. I would wrap it in quotes and add the function
mysql_real_escape_string()
. That will protect you from most attacks. So your line would look like:There are a few factors you'll want to consider when deciding where to store temporary data. Session storage is great for data that is specific to a single user. If you find the default file-based session storage handler is inefficient you can implement something else, possibly using a database or memcache type of backend. See session_set_save_handler for more info.
I find it is a bad practice to store common data in a user's session. There are better places to store data that will be frequently accessed by several users and by storing this data in the session you will be duplicating the data for each user who needs this data. In your example, you might set up a different type of storage engine for this wave data (based on wave_id) that is NOT tied specifically to a user's session. That way you'll pull the data down once and them store it somewhere that several users can access the data without requiring another pull.
$_SESSION mechanism is using cookies.
In case of Firefox (and maybe new IE, I didn't check myself) that means that session is shared between opened tabs. That is not something you expect by default. And it means that session is no longer "something specific to a single window/user".
For example, if you have opened two tabs to access your site, than logged as a root using the first tab, you will gain root privileges in the other one.
That is really inconvenient, especially if you code e-mail client or something else (like e-shop). In this case you will have to manage sessions manually or introduce constantly regenerated key in URL or do something else.
You might want to consider how REST-ful this is?
i.e. see "Communicate statelessly" paragraph in "A Brief Introduction to REST"...
(or any of the other links on wikipedia for REST)
So in your case, the 'wave_id' is a sensible Resource to GET, but do you really want to store it in the SESSION? Surely memcached is your solution to cacheing the object Resource?
Well Session variables are really one of the only ways (and probably the most efficient) of having these variables available for the entire time that visitor is on the website, there's no real way for a user to edit them (other than an exploit in your code, or in the PHP interpreter) so they are fairly secure.
It's a good way of storing settings that can be changed by the user, as you can read the settings from database once at the beginning of a session and it is available for that entire session, you only need to make further database calls if the settings are changed and of course, as you show in your code, it's trivial to find out whether the settings already exist or whether they need to be extracted from database.
I can't think of any other way of storing temporary variables securely (since cookies can easily be modified and this will be undesirable in most cases) so $_SESSION would be the way to go
$_SESSION items are stored in the session, which is, by default, kept on disk. There is no need to make your own array and stuff it in a 'dataentry' array entry like you did. You can just use $_SESSION['pcode'], $_SESSION['modules'] and so on.
Like I said, the session is stored on disk and a pointer to the session is stored in a cookie. The user thus can't easily get ahold of the session data.