Keeping config information in $_SESSION
Moderator: General Moderators
Keeping config information in $_SESSION
I've been doing this for my most recent script because it's so easy; no more includes needed in every function etc. But then I started wondering if it's safe to do this... Can anyone answer that question?
storing in $_SESSION is acceptably safe. The biggest issue with using $_SESSION is session timeouts, or the hosting clearing the cache folder, both equating in the data being lost and your user resulting to default settings.
a 'backup' method that I have used before is to check that the data is contained within $_SESSION, if it is not, then retrieve the settings from a more permanent source, e.g. a database table. Store the user's unique identifier in a cookie variable, if this too is lost, then redirect the user to a login screen.
a 'backup' method that I have used before is to check that the data is contained within $_SESSION, if it is not, then retrieve the settings from a more permanent source, e.g. a database table. Store the user's unique identifier in a cookie variable, if this too is lost, then redirect the user to a login screen.
Code: Select all
<?php
session_start();
if (empty($_SESSION['jmt_CONFIG'])) {
if (empty($_COOKIE['jmt_USER_ID'])) {
header('Location: http://www.mysite.com/login.php');
} else {
$_SESSION['jmt_CONFIG'] = pseudoRetrieveSettingsFromDataBaseFunction($_COOKIE['jmt_USER_ID']);
}
}
?>Well, they don't have to be stored like that, no. But it's a lot easier for me because I can use them in any function without globalising anything. When the session is empty it will just reload the file so time is not really an issue. The only problems I can think of are memory usage -which has been fine so far- and security.Jenk wrote:passwords and other such items do not need to be dynamically stored like that, especially in a variable that will dissapear after a set time.
The 'best' method for storing database credentials is to keep the information in flatfile, in a folder that is above the document root (and ftp root, if you have one,) and 'include' it when necessary.
Another method is to maintain all configuration settings that are server side configurations in a specific config file, like many applications do.
The desire to have a consistent method for accessing settngs, without global variables, is very common. Another solution, that avoids the need to use the session (which should generally be used for variables that only last the length of a session) is the Settings Class.nutkenz wrote:Well, they don't have to be stored like that, no. But it's a lot easier for me because I can use them in any function without globalising anything.
There is an article describing what a Settings Class is, and also the fully functional code for it (in just one page).
Wihtout wanting to go offtopic.. in the Settings Class, the get function:
Now.. the 'return false;' contradicts the ability to return multiple settings, right? Or am I missing something?
What if, like the article uses as an example, the setting I wish to retrieve is db.host or db.user, that will look for (and not find) just 'db' ?
This is more a question of "What am I missing?" than anything
Code: Select all
function get($var) {
$var = explode('.', $var);
$result = $this->_settings;
foreach ($var as $key) {
if (!isset($result[$key])) { return false; }
$result = $result[$key];
}
return $result;
}What if, like the article uses as an example, the setting I wish to retrieve is db.host or db.user, that will look for (and not find) just 'db' ?
This is more a question of "What am I missing?" than anything
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
I think you're getting confused by the variables. The author reuses both the parameter variable, and the $results variable. It's a horrible practice (reduces readability - as you seem to be evidence of
).
$result first points to $settings['key1'], then on the second loop iteration to $settings['key1']['key2']. If key1 does not exist - the value won't either. If it does, it may be an array of detailed settings as in db.name, db.user, etc.
I added something similar a while back, and yes I found it seemingly unintuitive too...
Left out the isset() check - probably causes a notice level error when running under E_ALL as a result...
$result first points to $settings['key1'], then on the second loop iteration to $settings['key1']['key2']. If key1 does not exist - the value won't either. If it does, it may be an array of detailed settings as in db.name, db.user, etc.
I added something similar a while back, and yes I found it seemingly unintuitive too...
Code: Select all
public function get($var) {
$pieces = explode('.', $var);
switch(count($pieces))
{
case 2:
return $this->settings[$pieces[0]][$pieces[1]];
break;
case 1:
return $this->settings[$pieces[0]];
break;
default:
return null;
}
}- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
nutkenz wrote:no more includes needed in every function etc.
These comments indicate that you are doing it for some sort of covenience. This method will probably have worse performace than just including a file.nutkenz wrote:When the session is empty it will just reload the file so time is not really an issue. The only problems I can think of are memory usage -which has been fine so far- and security.
This comment indicates that there is probably a design problem underneath this question. You are trying to deal with globals, but I don't think stuffing them into $_SESSION is the best way to go. The session is for session state data, not site state data.nutkenz wrote:But it's a lot easier for me because I can use them in any function without globalising anything.
(#10850)