Cookie Settings
Moderator: General Moderators
-
Beans
- Forum Commoner
- Posts: 49
- Joined: Mon Dec 23, 2002 3:06 am
- Location: Manila, Philippines
- Contact:
Cookie Settings
Hi Guys!
I have a script for authentication which has no problems on almost all installations. However, there's this one installation wherein I've debugged my script and it all boils down to the fact that the cookies are not saved.
This has nothing to do with the browser settings as I use the same browser to check out other users of my script.
Now, the question is, is there something in Apache or PHP.ini which tells the server not to allow setting of cookies? I use PHP's setcookie() to save the username and password for the session.
Your help is greatly appreciated. Thanks!
I have a script for authentication which has no problems on almost all installations. However, there's this one installation wherein I've debugged my script and it all boils down to the fact that the cookies are not saved.
This has nothing to do with the browser settings as I use the same browser to check out other users of my script.
Now, the question is, is there something in Apache or PHP.ini which tells the server not to allow setting of cookies? I use PHP's setcookie() to save the username and password for the session.
Your help is greatly appreciated. Thanks!
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
If it works on some servers but not on others it's possible it could be a register globals thing - try $_COOKIE['cookie_name'] if you aren't using that already.
Otherwise, one of the first things I check if I've got a cookie problem is the path:
http://www.netscape.com/newsref/std/cookie_spec.html
Otherwise, one of the first things I check if I've got a cookie problem is the path:
http://www.netscape.com/newsref/std/cookie_spec.html
path=PATH
The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. The path "/foo" would match "/foobar" and "/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same path as the document being described by the header which contains the cookie.
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
What code are you using to echo the cookie?
or
or
Also check your temporary internet files to see if the cookie is being saved to your computer.
Mac
Code: Select all
echo $cookie_name;Code: Select all
echo $_COOKIE['cookie_name'];Code: Select all
echo $HTTP_COOKIE_VARS['cookie_name'];Mac
-
Beans
- Forum Commoner
- Posts: 49
- Joined: Mon Dec 23, 2002 3:06 am
- Location: Manila, Philippines
- Contact:
Ok.. I'll clarify a bit.
I have 1 file called vAuthenticate.php which has the code snippet below:
Take note that $username and $password came from a login page and since register_globals is turned on, I don't need to use $_POST.
Now, towards the end of vAuthenticate.php, I've got some if-else statements which has some javascript to redirect the user to a specific URL. Let's say it redirected me to page1.php, I have this code in page1.php:
Notes:
1. The temp folder settings is ok and is set to "/"
2. This works on 99% of the people who downloaded my script. Only 1 person has this problem, that's why I suspect its the apache or php settings that's screwed up.
3. page1.php is either in the same directory or under the directory where vAuthenticate.php lies. So, the problem of cookie scope is out of the picture.
Hope you guys can help out.
I have 1 file called vAuthenticate.php which has the code snippet below:
Code: Select all
setcookie('USERNAME', $username);
setcookie('PASSWORD', $password);Now, towards the end of vAuthenticate.php, I've got some if-else statements which has some javascript to redirect the user to a specific URL. Let's say it redirected me to page1.php, I have this code in page1.php:
Code: Select all
echo $USERNAME;
echo $PASSWORD;Notes:
1. The temp folder settings is ok and is set to "/"
2. This works on 99% of the people who downloaded my script. Only 1 person has this problem, that's why I suspect its the apache or php settings that's screwed up.
3. page1.php is either in the same directory or under the directory where vAuthenticate.php lies. So, the problem of cookie scope is out of the picture.
Hope you guys can help out.
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
Although since register_globals is both off by default and deprecated it may be an idea to start using the superglobals in order to have a script which is forward compatible and compatible with default installations of PHP.Beans wrote:Take note that $username and $password came from a login page and since register_globals is turned on, I don't need to use $_POST.
Are you sure this one person hasn't got register_globals off?I have this code in page1.php:Code: Select all
echo $USERNAME; echo $PASSWORD;
2. This works on 99% of the people who downloaded my script. Only 1 person has this problem, that's why I suspect its the apache or php settings that's screwed up.
Have you checked in your temporary internet files (or wherever your browser stores cookies) to see if the cookie is being set?
Mac
-
Beans
- Forum Commoner
- Posts: 49
- Joined: Mon Dec 23, 2002 3:06 am
- Location: Manila, Philippines
- Contact:
Yep.. I'm pretty sure that the person't register_globals is turned on. I asked him to upload a file with phpinfo() in it.
Also, I tested it in my machine at home, at work, and at a friend's house. This does not work. He tested it in his machine and got the same problem. So I guess it doesn't depend on the client side of things.
I tested other people's installation and it worked fine on the places I mentioned a while ago.
Weird stuff isn't it?
Also, I tested it in my machine at home, at work, and at a friend's house. This does not work. He tested it in his machine and got the same problem. So I guess it doesn't depend on the client side of things.
I tested other people's installation and it worked fine on the places I mentioned a while ago.
Weird stuff isn't it?