# php sessions



## DrP (Jul 23, 2005)

I'm building a website for school which uses PHP sessions.
The site works fine on my local WAMP server and even on a spare web-package I have on the real internet.
However, when operated on the school server, the sessions are not working. As soon as a new page is requested, the user is logged out because the session variables are not being carried over.
Thanks to people on here I managed to get a copy of the php.ini file and change the location for sessions to be kept, and made a tmp folder for them. Still, the sessions are not working!
I have noticed that when I run phpinfo() in a file on the server that, under the Sessions heading, the session.save_path is different from the php.ini file. Could this be the cause?
Or, does anyone have any other suggestions?


----------



## Sequal7 (Apr 15, 2001)

DrP said:


> I have noticed that when I run phpinfo() in a file on the server that, under the Sessions heading, the session.save_path is different from the php.ini file. Could this be the cause?


Where did you place the session folder? 
Is Session Support listed as "Enabled" in the session table?
Did you restart the apache server after changing the variable? If so, then are you sure that you edited the correct php.ini file. The location varies by OS so you may have more than one php.ini file, but only one will be used. It's location will be written in the 
Configuration File (php.ini) Path in your phpinfo.php output file.


----------



## DrP (Jul 23, 2005)

The sessions are enabled. The school site operates on a sub-domain and to change the php.ini file I had to get a copy of the one for the whole server and edit it and put it in our own root directory. The people running the server did this for me. I have to go through someone else (buraeucracy) to communicate with them and was wondering if I could identify the problem myself.

Should this be showing in phpinfo()?
session.save_path	/var/lib/php/session	/var/lib/php/session
Because when I run the same phpinfo() query on sites hosted on my resellers package I get this:
session.save_path	/tmp	/tmp
...which makes sense because I want the sessions to be saved in a tmp folder in my root directory. Surely, the school session.save_path should be the same (or at least end in /tmp).
Is that the problem or am I barking up the wrong tree?


----------



## DrP (Jul 23, 2005)

If it makes any difference, when I ask the scripts to print the session ID it prints it no problem. Just that any variables in a session aren't being carried over.


----------



## Sequal7 (Apr 15, 2001)

> The school site operates on a sub-domain and to change the php.ini file I had to get a copy of the one for the whole server and edit it and put it in our own root directory.


Unfortuantely that wont work, only the *servers php.ini* file can be modified for any modifications to effect the operation of the servers sessional data, You cant run a php.ini file from your webspace root folder.

Can you access the server logs to see what sessional error's are written?

The different folders from your reseller account and the school may be a simple as they are using different server software (Apache and Linux for example)


----------



## DrP (Jul 23, 2005)

Are you sure about the php.ini file in my root not working? The people running the server have given me the copy and even edited it themselves to point the session.save_path to my tmp directory.
Do you know anything about what I'm seeing with phpinfo()?


----------



## Sequal7 (Apr 15, 2001)

What is the *Configuration File (php.ini) Path* in the phpinfo file on your server, that is where the servers php file is. It more than likey will say C:\WINDOWS\php.ini if its a windows server, or C:\apache\bin\php.ini etc.

I am certain it *wont be* your server space root folder location, but I have been wrong before!

I know allot about your phpinfo page, what do you need to know about it?


----------



## DrP (Jul 23, 2005)

Under the sessions section of phpinfo it has a row called "sessions.save_path".
Should this contain the address of the folder the sessions are being kept in?

As for the config file path:
Configuration File (php.ini) Path /etc/php.ini

but shouldn't the following be pointing towards the root directory on my subdomain?

Scan this dir for additional .ini files /etc/php.d

ps Thanks for helping like this.


----------



## Sequal7 (Apr 15, 2001)

In essence, yes your server should show the session.savepath as your webspace account or folder if that is where phpinfo is run from.

The post you just made is just as I expected in that I am correct, your server is running Linux and its looking at the etc folder (which is like the windows C:\ folder), so the php.ini file in your hosting folder that you have edited is useless.

No it wont point to your web folder. your script isn't written for running under linux OS.

Try this script to see if sessions work at all.
name this page1.php

```
<?php
// page1.php

session_start();

echo 'Welcome to page #1';

$_SESSION['favcolor'] = 'green';
$_SESSION['animal']  = 'cat';
$_SESSION['time']    = time();

// Works if session cookie was accepted
echo '<br /><a href="page2.php">page 2</a>';

// Or maybe pass along the session id, if needed
echo '<br /><a href="page2.php?' . SID . '">page 2</a>';
?>
```
then name this page2.php


```
<?php
// page2.php

session_start();

echo 'Welcome to page #2<br />';

echo $_SESSION['favcolor']; // green
echo $_SESSION['animal'];  // cat
echo date('Y m d H:i:s', $_SESSION['time']);

// You may want to use SID here, like we did in page1.php
echo '<br /><a href="page1.php">page 1</a>';
?>
```
Upload both files to your web space root folder, then call the *page1.php*script. 
It should show "*Welcome to page #1"* and two links below that "*page2*", click either one of the *page2* links and if sessions are enabled and set correctly (which I suspect they are) then you should get a string that says greencat and the date/time and below that the link should turn to *page1* below it.

If that works then sessions is fine and your script isn't designed to run on a Linux system so you would have to edit it, or find something that does the same as that one does but is designed for windows or apache servers. If it doesn't function as described then sessions is corrupt in php.ini file located in the etc folder, or the session tmp folder isn't writable . The admin should fix that on the server.


----------



## DrP (Jul 23, 2005)

Thanks for that. It looks like the school server is down at the moment so I'll have to try those scripts later.
You've cleared a few things up. I didn't realise PHP scripts would need to be written differently for a Linux system. How much difference is there?
Also, my own site packages are hosted on 'Red Hat Linux Enterprise servers' - surely that's Linux too? The site I am having problems with actually works if I put it on one of my own packages.


----------



## Sequal7 (Apr 15, 2001)

There isn't allot of differences, mostly security and some handlers but code may not be compatible as written from one server environment to another and they will require debugging.

Try to compare the phpinfo file on both of your Linux servers (school one and your hosting providers) and see where the difference's are, that may lead you to the correct answer too.


----------



## DrP (Jul 23, 2005)

Ok. I'll compare them and see what differences I can see (when the school server is back in action).
In the meantime, could you give me more info on differences in PHP across different servers? I was under the imporession that PHP was PHP and that was that. How does it differ? I'm assuming global variables is off so that shouldn't be a problem.
This is the script that is failing me on the school server. Can you see anything?
<?php
session_start();
if ((isset($_SESSION['user_logged']) &&
$_SESSION['user_logged'] != "") ||
(isset($_SESSION['user_password']) &&
$_SESSION['user_password'] != "")) {
$_SESSION['logged'] = TRUE;
} else {
$redirect = $_SERVER['PHP_SELF'];
header("Refresh: 2; URL=login.php?redirect=$redirect"); 
include "includes/header.inc.php";
echo "

You must be logged in to view this page. We are redirecting you to the login page.

";
include "includes/footer.inc.php";
die();
}
?>
Again, thanks for the help.


----------



## Sequal7 (Apr 15, 2001)

It can be as simple as UPPERCASE and lowercase. I see not obvious errors in that script so I cant help you with the code.

try adding this just above session_start(); 

```
error_reporting (E_ALL ^ E_NOTICE);
```
 and see if anything is printed in the headers.


----------



## DrP (Jul 23, 2005)

Here's what I get when I run your scripts. I gather this means there's a problem?

Page 1 shows:

Welcome to page #1
page 2
page 2

Page 2 (both of them) shows:

Welcome to page #2
1970 01 01 01:00:00
page 1


----------



## Sequal7 (Apr 15, 2001)

There certainly is a problem with the server. The date function isn't even close to being correct. Your session would never work because the server's timezone appears to be way off.

Send an email to your admin and have them check the php.ini file for the correct time zone;










and the correct sessions folder










The problem lays with their setup and not your code.


----------



## DrP (Jul 23, 2005)

I'm in the UK - does that mean the timezone's still way off?
Thanks for your help. I'm relieved my codes ok, too.


----------



## Sequal7 (Apr 15, 2001)

Yes, something with your server is screwed.....Ask your IT department to repair it, the time shown was 1970, and I am pretty sure that your not back in the 70's in the UK, although it may seem like it from time to time....That code shows your sessions aren't working at all. How can you create a session when its 1970 and sessions are for today?


----------



## DrP (Jul 23, 2005)

Point taken!
I've emailed my go-between to pass that on to the people the authority pay to run the server. What's shocking is that the server people haven't been able to work this out.


----------



## Sequal7 (Apr 15, 2001)

I agree, it is shocking that they haven't been able to figure that out. You say you have two linux services, try the code on the other Linux service (your paid hosts) and see what comes up. You should see a difference in the codes output.

Sounds like the IT department isn't very IT inclined since its a simple fix from the server end.


----------



## brendandonhu (Jul 8, 2002)

The date is printed wrong because $_SESSION['time'] is empty. A timestamp of 0 = January 1, 1970.


----------



## Sequal7 (Apr 15, 2001)

Its not empty, it obtained from the first page on submission, it is given from the server. The server isn't storing sessions so the time stamp can not be retrieved from the page's submission.

from page 1
$_SESSION['time'] = time();

to page two
echo date('Y m d H:i:s', $_SESSION['time']);

its also not storing the session for

$_SESSION['favcolor'] = 'green';
$_SESSION['animal'] = 'cat';

which mean its defunct.


----------



## brendandonhu (Jul 8, 2002)

Right, $_SESSION['time'] is just not set there. It's not a timezone problem.


----------



## Sequal7 (Apr 15, 2001)

Sorry I must have misunderstood you, I thought that you were eluding that it was a different problem.

My bad for jumping to conclusions....


----------



## DrP (Jul 23, 2005)

Ok, so there may be nothing wrong with the server's timezone. Instead it's just the sessions not being passed? I see Brendan's point about zero returning 1970.
What makes the problem worse is that the server is dealt with by an external agency (RM, I think) but I have to contact the county education authority's IT support people, who know less than I do.


----------



## Sequal7 (Apr 15, 2001)

There is nothing wrong with the server timezone settings, the problem is in the php.ini file, apache httpd.conf file or vhosts file. My post about the 1970 was sarchastic and it meant to emphasize that there is no relation to you being in the UK not that your server time is out.

Basically either the *web server* or the *subdomain* that your using isn't setup correctly.

Send them (the IT department) a link to your site with the code your using for your sessions and tell them clearly what the problem is. 
If you have access to the servers root folder try sending the code in the example and see what happens, that may assist you in troublshooting if its a httpd.conf or vhost problem, or a local server one. 
You may want to request this tread be moved to a Unix/Linux forum where you may get more support since its not a development problem anymore.


----------



## DrP (Jul 23, 2005)

Ok. Thanks for all your help Sequal7.


----------

