Page 1 of 1

Keeping config information in $_SESSION

Posted: Mon Jul 03, 2006 4:33 am
by nutkenz
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?

Posted: Mon Jul 03, 2006 6:08 am
by Jenk
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.

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']);
    }
}

?>

Posted: Mon Jul 03, 2006 6:49 am
by nutkenz
Ok, but specifically I'm talking about the config info for my website; such as database passwords etc.

Posted: Mon Jul 03, 2006 6:56 am
by Jenk
If your site requires all users to login upon session expiration, then yes, it can be a viable method of ensuring your config data is in a superglobal.

But of course, it will require permanent storage (i.e. the user name, host and password will need to be hardcoded somewhere..)

Posted: Mon Jul 03, 2006 7:02 am
by nutkenz
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.
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.

Posted: Mon Jul 03, 2006 7:05 am
by jamiel
Its silly to store database connection details in every user's session. Just put them in constants, or make a database wrapper class. The only details that should be in the session are user specific details.

Posted: Mon Jul 03, 2006 7:08 am
by Roja
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.
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.

There is an article describing what a Settings Class is, and also the fully functional code for it (in just one page).

Posted: Mon Jul 03, 2006 9:33 am
by Jenk
Wihtout wanting to go offtopic.. in the Settings Class, the get function:

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; 
    }
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 :)

Posted: Mon Jul 03, 2006 10:06 am
by Maugrim_The_Reaper
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...

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;
		}
	}
Left out the isset() check - probably causes a notice level error when running under E_ALL as a result...

Posted: Mon Jul 03, 2006 1:06 pm
by Christopher
nutkenz wrote:no more includes needed in every function etc.
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.
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:But it's a lot easier for me because I can use them in any function without globalising anything.
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.