Session vs. Cookie

Trid3nt

Hey guys, I've got a bit of a conundrum.

I need to transfer arrays of information back and forth between pages. I've used sessions in the past to be the container, but my client has globals turned off.

I figured I could just use $HTTP_SESSION_VARS rather than the $_SESSION shortcut, but I read on php.net that session_register($var_name) doesn't work if globals are turned off. I don't quite know what to make of this... it doesn't seem like they'd have anything to do with each other. But you guys will know better than I.

I then moved to cookies because that seemed to work, but I didn't test it on arrays of information which apparently don't work. 🙁 I'm dying to figure out what is up and how I can best solve this issue.

Any thoughts?

Btw, they're also using an ancient version of PHP -- 4.0.1. Not sure if that makes a difference, but I've noticed some of the functions I normally use don't work and I have to kludge it somehow.

swr

Using $SESSION[] should work fine even without register_globals. Just use [man]session_start[/man] like usual, and $SESSION will persist between pages.

Using 4.0.1 would require $HTTP_SESSION_VARS instead of $_SESSION, but I would stongly advise upgrading PHP instead of backporting your code. There may be security holes in 4.0.1 that are patched by later releases.

[Edit]
Just to clarify, you don't need to use session_register when using $_SESSION[], so the fact that session_register doesn't work with register_globals off doesn't matter.

Trid3nt

First off, thanks for the reply!

Unfortunately it still doesn't work for me. I use session_start() at the beginning of every page that I need the session variables on and they don't persist. I also found out that register_globals is actually on, but that session_register('user') won't create a variable called $_SESSION['user'] that persists as well... I'm baffled by what is going on!

swr

If you're still on 4.0.1, $_SESSION[] doesn't exist, so you'd need to use $HTTP_SESSION_VARS.

Secondly, the [man]session_register[/man] manual page warns against what you are doing:

Caution
If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered(), and session_unregister().

Don't use session_register. Upgrade PHP (so you can use $_SESSION instead of $HTTP_SESSION_VARS) and follow the examples in the [man]session_start[/man] manual page.

Trid3nt

Yes I've seen that caution message. Is there no way to solidly use SESSION variables on PHP 4.0.1? If so, they need to add that to a caution too... sessoins are pretty important.

I ended up stumbling on the answer yesterday, but it is probably a kludge.

For some reason no combination that I tried worked except for this one:

1. session_start() at the top.
2. session_register('user') before I set the variable.
3. $user = 1 when I set the variable.
[/LIST=1]
For some reason, this combination allows me to use this on the next page:
```
if(!$HTTP_SESSION_VARS['user']){
     // send them back
}
```
Any ideas on why this worked? I guess it hinges on them keeping global variables on, but they are really adverse to change and don't want to upgrade their PHP because they "Don't want to mess with what works." It will take some convincing for me to make them realize that it isn't working... oh well. Now to code the rest of it! 🙂

Thanks for the help guys!

swr

Don't know why it works, but the manual says not to, which means it's a bad idea. Just because it works sometimes doesn't mean it always will.

Considering your circumstances, I'd suggest creating a function for setting a session variable, and another for getting a session variable. Put all your $HTTP_SESSION_VARS / session_register() / whatever stuff in those functions, and have the rest of the code use those functions instead of accessing session stuff directly. That way, when the server gets hacked (inevitable on an un-maintained machine) and the owners finally decide to update their software, you will hopefully only have to change those two functions to make it work with a newer version of PHP.

Trid3nt

That's a great idea! I will definitely look into that. Hopefully it won't take long for them to realize that an upgrade would do them well.

Thanks again!