Session vars and file includes

Stinger51

I am trying to pass a session variable to a file that contains some functions :

session_register('svPath');

I then set svPath, depending upon whether I am running on my local server (for testing) or my web host :

if (local)
svPath = "apache/local_folder/";
else
svPath = "webhost/remote_folder/";

I then include the file with the functions that I call that also need this path :

include $svPath . "MyFuncFile.php";

The problem is, when I try calling a function in MyFuncFile that also needs this path information, it is not there, even after making sure that MyFuncFile begins with :

session_start();

For example, if a function in this file tries to use svPath for opening other files, I get an error because svPath is null.

Is what I am doing possible -- or will this simply not work, trying to tell a file you are including what the value of a session variable is?

I hope that all makes sense. Otherwise, I may be doomed to passing this path information as a parameter to each and every function that needs it.

mattuu

There are a lot of things that could be going wrong. First of all, you should set the variable, then register it. Do your if ($local) and assign it, THEN session_register() it.

Second, your session_start() should be called first -- before you session_register().

Third, you don't need to call (and SHOULD NOT call) session_start() again from inside the included file.

When you look for the path information fom inside the included file, you may need to reference $_SESSION[variable] instead of just $variable. Alternately, you may need to declare $variable global from inside the function in order to access it, but you should be careful of the security implications of such (be sure that you've set that variable before using it, don't allow user-passed variables to be used in an include statement!)

If this doesn't help, post the code from as simple of a test case as you can come up with that demonstrates the issue.

Stinger51

Thanks, I forgot that I had to declare the session variable inside the function as a global. The function is now receiving the value.

I am not clear on the security issues of this, however. You say to be sure to set this session variable before using it. So doesn't setting it on the calling form accomplish this?

Thanks for your help.

mattuu

If you mean, "setting it on the calling form", as in, the HTML Form that is posting the data, then no, that can't be trusted. Rule #1 is to never trust user input. You never want to take for granted that a user has passed a given variable, or has passed it in an expected manner. Let's do an example. You set up a form to update someone's password, and it looks something like this:

<FORM METHOD=POST ACTION="changepass.php">
Your new password: <INPUT TYPE=password name=password size=12><BR>
Confirm password: <INPUT TYPE=password name=confirm_password size=12><BR>
<INPUT TYPE=HIDDEN name=userid value=<?php echo $userid?>>
<INPUT name=submit type=submit value="Change Password">
</FORM>

Now, the trick is to look at the 'hidden' input. Imagine the php code that might process the form. I'll skip the details, but one line might look like this:

$sql = "UPDATE users set password='$password' where users_idx='$userid'";
$result = mysql_query($sql);

Uh, oh. You're in deep now. Because a person can easily fake a form submit, and pass ANY userid they want.

Now, imagine if a user somehow discovers you use a variable called svPath. What if they query somepage.php?svPath=/etc -- will your code handle this? Is there a chance that the svPath variable will NOT have been set in the session at some point? Even with register_globals, a person can't pass a GET or POST variable to overwrite a session variable unless you change the variable order -- which does session variables last, overwriting any previous variables. But if you have a circumstance where you just say,

global $foo;

and then use $foo, you have to be sure that $foo CANNOT be a user variable passed through something like somepage.php?foo=bar, otherwise you're risking your security.

Admittedly, this is pretty vague, but the best way to think about things is to constantly think to yourself: knowing what I know, if I was a user, could I break my code in ways I do not intend for it to be breakable?

the_Igel

the main trick with all that security issues is that

turning register_globals ON and not setting initial values to variables and all the rest common flaws everyone gets blamed for
DEFINITELY DO NOT always mean a security hole. But it's much easier to evade these potential holes than to think every now and then about do something mean a hole or doesn't.