[akozlik]

Alright, I come to you all with a problem.

I am currently working on an authentication system that was built before I took over the site. Everything was working fine, but all of a sudden the sessions are changing the id when I go to a particular page.

I have pages index.php, admin.php, set_order.php.

All three of the pages have session_start() at the top, and nothing before them.

The user logs in at index.php, and is redirected to admin.php. At this point the session stays the same. However, moving from admin.php to sort_order.php causes the session_id() to change, thus logging my users out. the set_order.php file is located in the 'scripts' directory.

Finally, this is the content of set_order.php.

<?php

session_start();

if (isset($_GET['order'])) $_SESSION['order'] = $_GET['order'];
header("Location ../admin.php");

?>

When I echo out session_id() on that page, it's different.

Any help would be greatly appreciated. I'm about at my wits end here.

This post has been edited by akozlik: 06 October 2008 - 11:50 AM

[William_Wilson]

you probably don't want to post the entire admin.php, but could you at least show us some of it? There must be something in that code that is changing it. Are you switching on a header/exit method or a clicked link?

[akozlik]

Basically the admin.php gets to the set_order.php page by dynamically creating a link like

set_order.php?order= and then whatever order to sort by.

The sessions stay the same from index.php to admin.php, but change when it navigates to the set_order.php file. The set_order file sets a session variable, and then redirects via a header()

Also, I just tried changing the link

<a href="scripts/set_order.php?order=last_name">

to

<a href="admin.php?order=last_name">

That didn't work either, so something weird's going on. All my links are relative paths, and not direct URLs.

[William_Wilson]

have you tried printing the id at the beginning and end of the admin.php page? It seems most likely this is the culprit as there is little code in set_order to do anything, let alone change the id, also have you checked any includes for problems?

Without more php code it is hard to know what is causing it.

This post has been edited by William_Wilson: 06 October 2008 - 12:41 PM

[akozlik]

Yes I've tried doing that as well, and the session stays the same.

I'm working on using session_regenerate_id() to see if I can get something working.

[William_Wilson]

limiting the code in your admin page may help track it down as well. Try commenting out all lines that use includes and anything that occurs more than once, like your links, so that only 1 remains, this will allow you to comment them out one or a few at a time and find it, I've run into these random issues myself and often it is simply an overlooked line.

[akozlik]

That's the thing is that most of the code on the admin.php page is simply making some queries, looping through the results and echoing them out the page. There aren't many included files, and those that are included, I ran through the session_ids and they were fine. The problem's only happening when I refresh the admin.php, or link to another page from it.

[JackOfAllTrades]

Is the app not using cookies for session ID transmission, and the PHPSESSIONID is not being passed in the URL that's constructed? Could there be a permissions problem on the directory where sessions are stored?

Just a couple of WAGs.

[William_Wilson]

the fact that refreshing the admin page breaks it leads me to think that permissions aren't at fault, but I could be wrong.

Do any of your includes call session_start() ? It should only be called once per page load and can do odd things if it is called more than once.

[CTphpnwb]

William_Wilson, on 6 Oct, 2008 - 01:33 PM, said:

Do any of your includes call session_start() ? It should only be called once per page load and can do odd things if it is called more than once.

I just tried to duplicate the problem but can't. Even with multiple session_start() calls.

<?php
session_start();
echo $_SESSION['order'];
$x= session_id();
echo "<br>Session #".$x."<br>";
	?>
	<form action="<?php echo $php_self ?>" method="get">
	Enter some text: <input type="text" size= 15 name="order" value="<?php echo $_GET['order']; ?>" />
	<input type="submit" value="Submit" />
	</form>
	<?php
if (isset($_GET['order'])) $_SESSION['order']= $_GET['order'];

session_start();
session_start();
session_start();

echo $_SESSION['order'];
$x= session_id();
echo "<br>Session #".$x."<br>";


foreach ($_SESSION as $key=>$value)
	{
echo "<br>Key: ".$key." Value: ".$value;
	}
?>

[engale]

I double checked like CTphpnwb did but also was unable to find an error, the only thing I can think is prehaps the ini file has the sessions set to a few seconds, this would then distroy the session file and when the session_start is called again generate a new. Only thing I can think that would really do it at this point.

[Moonbat]

When the new session is created, does the data from the old session (not including ID) get transferred to the new session?

If it does, then I would have to assume that session_regenerate_id() is being used somewhere else, and you should get rid of it wherever it is.

If it is not transferring other session data, then the session timeout is probably very small, and you probably will have to use ini_set() to change the session.gc_maxlifetime setting in your php.ini file to something bigger.

[akozlik]

The session holds data between the index and admin pages, but not when the admin page refreshes, or goes to the set_order page. The session is not timing out because it holds the session data between the working pages without timing out. I'm starting to think it's a server issue or something. I'll check the max_life setting in my ini and see if that works. I think I may end up rewriting the whole thing anyway, just because it runs super slow and needed some improvements.

[engale]

is there a session_destroy or unset in the documention anywhere that may cause this to happen?

[akozlik]

Nope, unfortunately I think it's a problem that lies farther than what's in the code. I'm going to be rewriting it this week though, so hopefully no problems will occur.