Printable View
I've got a session variable being registered on a PHP page.
When a user follows a link to the next page, the session is no longer available.
I'm using session_start(); at the top of my page, and the second page is within the same domain/directory.
Does anyone know what could be causing the loss of session?
have you registered your variable ?
ex :
session_start();
$myvar=0;
session_register("myvar");
try this if you have not, that should correct your problem.
That wasn't it but thanks anyway.
Turns out it was the way I was including one of my files... I was using an absolute reference - ie http://www.domain.com/folder/file.php which meant the included file couldn't access the session variables...
If you use a relative reference eg ../file.php it works fine.
:D
It's not a very good idea to use session_register() anymore with register_globals off by default. I wouldn't doubt that it will soon be deprecated, as well.
The correct way to do it is:
Code:$_SESSION['myvar'] = 0;
I just moved an app from one server to another and the PHP versions are definitely different. So I'd have to sort out all the different ini settings (register_globals, etc.).
But anyway, I have the user login with his own username which is kept in a MySQL DB. All users use the same MySQL username to access the DB.
On pages that need authentication, I have text that says, "Logged in as user: theUsername". Where theUsername is the unique username. But after visiting other pages on the same server (which all have session_start), the line is changed to, "Logged in as user: theSharedMySQLusername".
Unfortunately, I never noticed if this also occured on the old server.
I did also notice another anomaly. In one directory, it wasn't including (or rather "requiring") the file from the include_path. Although a file in a different directory was requiring it fine from the include_path setting. For this one folder, I had to put the included file in the same directory.
Both servers used the form $_SESSION['username'] = $theUsername;
In fact, the main change is that I just started using the include_path for this app. I would prefer if the session variable was not even available rather than apparently overwriting it with the MySQL shared username.
Any thoughts?
you should always use the absolute path and not a relative path, (the url) when including a file with include(). makes life so much easier.Quote:
Originally posted by ShowMeTheKey
That wasn't it but thanks anyway.
Turns out it was the way I was including one of my files... I was using an absolute reference - ie http://www.domain.com/folder/file.php which meant the included file couldn't access the session variables...
If you use a relative reference eg ../file.php it works fine.
:D
Phenix: yeah don't use include_path :p:
but I don't understand, it shouldn't override the session variable just because you are using a include_path. it has to be getting overwritten by another setting or variable.
I have this in an HTML form:
<input type="text" name="username">
Then I have this in a PHP script:
$username = $_POST['username'];//the unique username
Then I possibly corrupt it here:
require 'aFile.php';
Because aFile.php has:
$username = "theSharedMySQLusername";
mysql_connect($primary, $username, $password)...
(although I do not save it in a session at this point)
But the 1st strange thing is that after the require, I have:
$sql = mysql_query("SELECT * FROM UserTable WHERE User = '$username'");
Yet it apparently is using the unique username in the query since theSharedMySQLusername would return no rows, and later it shows that I am logged in as the unique username
(This may be a scoping issue against what the docs say -- the query should have used theSharedMySQLusername).
Then I set the session variable:
$_SESSION['username']=$username;
I figured I was storing the corrupted username here, so I changed $username to $uniqueUsername above in 3 places:
$uniqueUsername = $_POST['username'];//the unique username
$sql = mysql_query("SELECT * FROM UserTable WHERE User = '$uniqueUsername'");
$_SESSION['username']=$uniqueUsername;
Then I display who is logged in on an HTML page using the session variable. First it shows the unique username, then if I go to a different page and return, it shows theSharedMySQLusername.
Very frustrating.
Is register_globals off? I don't know if it'd have anything to do with it, but if register_globals is creating a variable named $username, and you then change that value, perhaps it's changing $_POST['username']. I highly doubt it, since I'm sure they're excusive.
But you might want to try using $sqlUsername and $uniqueUsername and see what happens?
Other than that, I'm clueless.
register_globals is On, but I changed to:
$uniqueUsername = $_POST['username'];//the unique username
$sql = mysql_query("SELECT * FROM UserTable WHERE User = '$uniqueUsername'");
$_SESSION['username']=$uniqueUsername;
But I am still using theSharedMySQLusername as $username -- which still matches the form input username.
From the docs...
Have you ever heard of register_globals affecting $_SESSION? It is when I use echo $_SESSION['username'] (and only after the first time) that it is tainted/corrupted.Quote:
When on, register_globals will inject (poison) your scripts will all sorts of variables, like request variables from html forms.
I'll probably come back to this on Monday and step through the code, although it isn't that urgent, just irritating.
if register_globals is on then you can't use any super global. you have to revert back to the old style.
session_register() and stuff, highly not reccomended
oh man, I just noticed that you set it twice. the last one will overwrite the posted one.Quote:
Originally posted by Phenix
I have this in an HTML form:
<input type="text" name="username">
Then I have this in a PHP script:
$username = $_POST['username'];//the unique username
Then I possibly corrupt it here:
require 'aFile.php';
Because aFile.php has:
$username = "theSharedMySQLusername";
mysql_connect($primary, $username, $password)...
(although I do not save it in a session at this point)
But the 1st strange thing is that after the require, I have:
$sql = mysql_query("SELECT * FROM UserTable WHERE User = '$username'");
Yet it apparently is using the unique username in the query since theSharedMySQLusername would return no rows, and later it shows that I am logged in as the unique username
(This may be a scoping issue against what the docs say -- the query should have used theSharedMySQLusername).
Then I set the session variable:
$_SESSION['username']=$username;
I figured I was storing the corrupted username here, so I changed $username to $uniqueUsername above in 3 places:
$uniqueUsername = $_POST['username'];//the unique username
$sql = mysql_query("SELECT * FROM UserTable WHERE User = '$uniqueUsername'");
$_SESSION['username']=$uniqueUsername;
you have this subbmitted
$username = $_POST['username'];//the unique username
but then you include a file that inlcudes this
$username = "theSharedMySQLusername";
you can't do that, change the name.. and most of it is in my post above this one. once you submit the form since register_globals are on then $username is filled by that and still used. and changed by mysql variable
Maybe it is using theSharedMySQLusername in the query, and I fell into the same trap that I was warning Money-4-Life about in thread "mySQL_Data_Seek ?!?!".
But I did change the variable name and theSharedMySQLusername should never enter the $_SESSION. I was wondering if the session may not have expired, but damn it, I changed the variable name so that $username does not enter into the $_SESSION.
I'll have to isolate why it was correct on the first page, but not subsequent pages. Anyway, that's a Monday deal.
Says who? My host has register_globals on, yet I still use the superglobals without a problem.Quote:
Originally posted by phpman
if register_globals is on then you can't use any super global.
you will. I have and I don't think it is anything I did.Quote:
Originally posted by The Hobo
Says who? My host has register_globals on, yet I still use the superglobals without a problem.
you've seen me saying it before so I most know what I am talking about.
I haven't. I can't find any information on it in the docs. Do you have an example of a problem it can cause?Quote:
Originally posted by phpman
you will. I have and I don't think it is anything I did.
Just because you say something often doesn't mean you know what you're talking about.Quote:
Originally posted by phpman
you've seen me saying it before so I most know what I am talking about.
wel you are right, I don't know what I am talking about. heck, I don't even know php. :rolleyes:
what do you think the super globals are for, for rgister_globals are OFF, if they are on then you shouldn't be using the super globals. it is only common sense.
play around with it, it will happen. but again it is not like I try to do it. I forgot I had turned it on and I was getting sparatic errors and empty variables until I realized it was on, turning it OFF fixed it all, so maybe it was a coincidence.
I don't believe people unless they provide proof. Saying "it happened to me!" and "I say stuff all the time, so I know what I'm talking about" isn't proof of anything.Quote:
Originally posted by phpman
wel you are right, I don't know what I am talking about. heck, I don't even know php. :rolleyes:
I don't know where your attitude is coming from, but it just makes you look dumber.
Provide documentation. Superglobals should be used REGARDLESS of register_globals. NEVER should you use native globals.Quote:
Originally posted by phpman
what do you think the super globals are for, for rgister_globals are OFF, if they are on then you shouldn't be using the super globals. it is only common sense.
Give me documentation or proof and I will believe you, but I'm not going to go hide and wait for the sky to fall.
My current host has had register_globals on for as long as I've been with them (a year or two). I've used superglobals for that full amount of time. I've NEVER had a problem. Isn't that long enough to make me believe it's okay?Quote:
Originally posted by phpman
play around with it, it will happen. but again it is not like I try to do it. I forgot I had turned it on and I was getting sparatic errors and empty variables until I realized it was on, turning it OFF fixed it all, so maybe it was a coincidence.
I've done some looking, but I don't find anything that says don't use superglobals with register_globals off.
http://www.php.net/variables.predefined
http://www.php.net/manual/en/configu...gister-globals
http://www.php.net/manual/en/securit...terglobals.php
no hobo I can't show you proof. like I said
I can't make it happen again so maybe it was a coincidence, but it will never happen again so I just don't use them if globals are on. but not to worry, I won't code for a server with them on anyway.Quote:
I forgot I had turned it on and I was getting sparatic errors and empty variables until I realized it was on, turning it OFF fixed it all, so maybe it was a coincidence.
there have been a lot of things I have run into but you never have. that makes me think you don't get to deep in php and I do. I test things, I play around. it also could be the setup on the 4 servers I run, who knows. it can be a lot of things. but if it fixes Phenix's problem then I don't know what to say.
we both been here long enough to trust one another, you should also know I don't say anything I don't mean. it happened to me and just because it doesn't happen on your server or you can't find anything doesn't make me a liar.
you may have things happen to you that nobody else has seen, it is all how it is setup and how you use them. not every server is the same. and I understand you want proof, and I would want the same, but you get what you get.
since I can't make it happen then it is null an void.
we will just wait to see what phenix finds.
also phenix, if you can't get the server admin to turn globals OFF then if you can use htaccess you can.
I understand. But if it isn't broke, why should I fix it?
I have register_globals off on my test server that's on my PC. It's on on my host's server. I couldn't get them to shut it off, because that would mean that every poor PHP programmer on the server would have to modify their crappy code. So I doubt my host would want to do that.
then you can turn them off with htacess just for you. :)
I asked my host, and got a half-assed answer:
Quote:
It takes more than having register_globals on to allow someone to exploit someone else's scripts - and there are many other easy ways to exploit poorly written scripts (with globals on or off) or script use inattention (ask anyone who has left an install file hanging around for phpBB and found their forum defaced, for instance).
that is phpbb faults for not deleteing it. I hate host like that.
can you use htaccess file?
Yeah, I'll give it a try right now.
Quote:
I said...
So just because there're other ways to exploit a script, we'll leave every option to the exploiter open?
Quote:
She said...
I don't believe that's what I said, thank you. register_globals is something of a red herring, and is not going to protect from poor coding, which is the number one issue with scripts. Any issue with having register_globals on is far, far outweighed by other methods by which a script can be exploited.
Thread closed.
I like how she implies that I'm a poor coder, too, yet anyone using the native globals (which is why register_globals is on), has to be a horrible coder themselves.
It is against the standard, afterall.
and she knows what poor coding looks like? what a winner.
Yeah, the .htaccess worked.
But question: if I put this in my root folder, will it effect every folder in there, or will I have to put a .htaccess in every folder that contain PHP scripts?
I think so, but I never tried it. it should as far as the htacess file is concerned but I am not sure about php side of things. run phpinfo in another directory adn see.
It will effect every other folder above the root directory, unless you have another .htaccess put somewhere to cancel it out.
Cool. Isn't there a way to also turn it off for the particular script? Like a way to turn it off for the script only.
I think I'd like to have it off for my news manager, because it probably is a security risk of some sort, and I'd rather be safe than sorry.
I think I remember someone talking about turning it off in code (but just temporary)?
ini_set("register_globals", 0);
but only works in that instance. you will have to run it each time the script runs. not a good way to do it.
But each time my script runs, it loads a config.php file to get the programs configuration variables. Wouldn't it work out fine if I put it in there?
just stick the htaccess in that folder that holds the news script. unless it is spread out over the root folder.
if the config file is loaded everytime then yeah it should work.
I didn't get a chance to muck with this until today. Thanks for the feedback guys.
Although I had already changed code to use $uniqueUsername in the calling scripts, I still had the error. But I would have to be sure that I changed it everywhere. So today I changed the included/required connection script to use $MySQL_username and that fixed it.
What exactly is this particular usage of htaccess that you guys are talking about?
It can control PHP settings for that folder and every folder under it without having to change the PHP ini itself. In our examples, it was the register_globals setting.Quote:
Originally posted by Phenix
What exactly is this particular usage of htaccess that you guys are talking about?