0

Short: For some reason, the cookie '_sid' isn't being retrieved by some browser/computers. Long: I have 3 files I'm using. /index.php, /scripts/login.php, and /iframes/register.php. Now when login info is entered, a bunch of standard stuff happen, and user is logged in. A cookie called '_sid' is set, and the value is stored in an mySQL table.

login.php:

setcookie("_sid", $sid, 0, '/'); ?>

Now all computers get this cookie - I've tested on over 15, all passed. Just wanted to show you how I set the cookie.

The problem lies in index.php:

<?php
$username="x"; $password="y"; $database="z";
mysql_connect(localhost,$username,$password);

@mysql_select_db($database) or die( "Unable to select database");
$loggedin=false; $team="none";
if(isset($_COOKIE['_sid'])){  //error happens here
    print_r("test");
    $session_id=$_COOKIE['_sid'];

Now the error occurs on the commented line. The isset returns false. Now normally this would be some sort of helpful indicator. However...

The third file, register.php, gives the user the ability register other people (irrelevant). The important thing to note is that the beginning of the file is the exact same as index.php.

<?php
$username="x"; $password="y"; $database="z";
mysql_connect(localhost,$username,$password);

@mysql_select_db($database) or die( "Unable to select database");
$loggedin=false; $team="none";
if(isset($_COOKIE['_sid'])){
    print_r("test");
    $session_id=$_COOKIE['_sid'];

This file, however, works. That's right, the isset works. This file also works on all 15/15 computers.

Now just to make this all the more confusing, index.php works on about 10 of the 15 computers. The error always occurs on mac (chrome, ff, safari) and Linux (ff tested, but fair to assume chrome too). It works on most windows (7+8 using chrome, ff). However, when using identical twin computers (on a ghosted os), one computer worked, and the other failed (using ff).

I've been at this problem for 2 days now, and really have no idea what to do...

fat_flying_pigs
  • 92
  • 1
  • 4
  • 14
  • Is the cookie only being set on login.php, or is there another file where the cookie can be set.. reason for asking: the cookie may be directory specific – CᴴᵁᴮᴮʸNᴵᴺᴶᴬ Feb 27 '13 at 09:08
  • 1
    Just out of curiosity, what is the reason to not use PHP builtin session handling? – hank Feb 27 '13 at 09:09
  • Do you get the same problem when you use empty instead of isset? There's a slight difference but you could try it out... – Toon Casteele Feb 27 '13 at 09:10
  • The cookie is only being set in login.php. I'll try adding the 5th parameter... I'm not sure why it isn't there. I'm not using built in sessions because eventually I will be allowing the user to remain logged in even after the browser is closed. – fat_flying_pigs Feb 27 '13 at 09:27
  • Can have persistent session in PHP builtin session handling also, refer http://stackoverflow.com/questions/9797913/how-do-i-create-persistent-sessions-in-php – Cyril Feb 27 '13 at 11:35

1 Answers1

0

When you set a cookie, the browser will add it the headers of new requests to the same domain.

You have to verify that login.php is called by the browser BEFORE index.php and NOT in the same request.

  1. login.php - browser send no cookie, but receive request to set it
  2. index.php - browser send the cookie

If in your index.php you have

<include "login.php">

this will definitely not work.

Ghigo
  • 2,312
  • 1
  • 18
  • 19
  • I don't have in my index.php. I'm slightly confused as to what you are saying; I use index.php before, during, and after the cookie is set. Within index.php, there is an iframe (/iframes/login.php). login.php posts to /scripts/login.php, which is where the cookie is set. – fat_flying_pigs Feb 27 '13 at 09:22
  • Why are you using an iframe for this? There is no reason and it makes things unreliable. Post to login.php on the main frame, then force a redirect with header('Location: http://your.site.com/index.php') – Ghigo Feb 27 '13 at 09:28
  • That's... actually a good point... What's this about the unreliable part though? Why and how? – fat_flying_pigs Feb 27 '13 at 09:35
  • Iframes and cookies are a mess. Google for it. You should also set a valid expiration (not 0) for the cookie. Browsers or third party security could block it. – Ghigo Feb 27 '13 at 09:46
  • 0 is valid expiration and would mean when the browser closes - the culprit is most likely the iframe. – hank Feb 27 '13 at 10:07