Keeping config information in $_SESSION

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
nutkenz
Forum Contributor
Posts: 155
Joined: Tue Jul 19, 2005 12:25 pm

Keeping config information in $_SESSION

Post 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?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

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

?>
nutkenz
Forum Contributor
Posts: 155
Joined: Tue Jul 19, 2005 12:25 pm

Post by nutkenz »

Ok, but specifically I'm talking about the config info for my website; such as database passwords etc.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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..)
nutkenz
Forum Contributor
Posts: 155
Joined: Tue Jul 19, 2005 12:25 pm

Post 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.
jamiel
Forum Contributor
Posts: 276
Joined: Wed Feb 22, 2006 5:17 am
Location: London, United Kingdom

Post 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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).
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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 :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
Post Reply