I'm having some weird issues with PHP Sessions. I've used them plenty of times on multiple sites, and from everything I can tell my code is fine. It's a friend's website and the host is IPowerWeb (which I'm convinced sucks, as this exact same code works on GoDaddy, HostMonster, and my WOS Portable drive). I'm fairly certain it is a configuration error either on their server or with the php.ini which I have limited control over (though at the moment, I am not changing any default settings). Oh and register_globals is off. I already checked that, and nothing in my code should cause issues with it anyway. But they are off. You can view the site here: http://www.haverdesign.com/ Anyway, for the most part sessions are working fine. The problem only occurs when I access a "folder" and have the web-server serve a default index file implicitly. To see what I mean, go to the site and login as the Demo Account. You will notice that you will always show as logged in if you click on the About Us, Gallery, and Links pages on the left. However, try clicking on the Home link repeatedly. You will see that sometimes it will detect you are logged in. Other times you are not. As soon as you click on any other link that explicitly addresses a file, however, you will be logged in 100% of the time. You will also notice the exact same issue occurs when you try to click 'My Projects' on the left. Since it hits the .../client/ folder, and doesn't specifically address to the index.php file there, it's also a gamble as to whether it comes up or not. I'm at my wits end trying to figure out what PHP configuration settings could be causing such odd errors so I'm hoping somebody has an idea... p.s. I could change the links to always explicitly go to the default index files, but I have other portions of the site this is not possible in so I need to resolve it rather than work around it. [edited for clarity... I hope] [Edited by - CaspianB on May 7, 2008 3:00:35 PM]

I think your best bet is to do a phpinfo dump and analyze the default settings of your hosting service. In particular pay attention to session.cookie_path . If this is not set correctly you may run into situations where you have multiple unique sessions for different branches on your webroot as opposed to one session for any branch on the web root which is what is typically wanted.

[edit] Sorry spoke before I actually looked at the site. The cookie path is set correctly at least on the cookie that Im sent and its not erased on viewing the home page although the home page says im not logged in. Are you sure you call session_start() on the home page?

It looks like its an issue with the cookie. If you go to /index.php it will work but with no page at the end it doesn't work. The cookie is not registering that / and /index.php are the same page.

The cookie seems fine to me. It always registers as / as it should which is read that this cookie is good for any page (and sub page/directory) under / or in your web root. If this value had changed to a different directory then it would be a sign of a setting issue. Its most likely an issue with your code and not the session. Do you have error logging to a file enabled, it can be very useful to track issues.

Thanks for checking it out. I'm still not certain what it is, but I tossed it up the ladder to their support team. I'm still convinced it's a server issue.

Quote:Original post by ju2wheels[edit] Sorry spoke before I actually
looked at the site. The cookie path is set correctly at least on the cookie that Im sent and its not erased on viewing the home page although the home page says im not logged in. Are you sure you call session_start() on the home page?

The session.cookie_path is set to '/' in the phpinfo dump. In fact, I've compared the entire session subsection from this webhost (IPowerWeb) to one of my personal webhosts that I have a mirror image of the site running on for development (HostMonster). The session settings are exactly the same in both phpinfo dumps, and my development site works perfectly.

Quote:It looks like its an issue with the cookie. If you go to /index.php it will work but with no page at the end it doesn't work. The cookie is not registering that / and /index.php are the same page.

Right, this is what I was trying to describe before. When you explicitly go to /index.php it always works. However, when you don't put the page name at the end it does still work. But it's random as to when it does and doesn't (try refreshing the site without the index.php page at the end. You'll notice it does show you logged in sometimes). At first, I thought the same thing - the cookie wasn't registering properly. Then I noticed it randomly DOES register. That's what is getting me.

I am confused how it would be an issue with the code... If you go to /index.php it works (which is the same page as when you go to '/' - and I did check to ensure they are hitting the same .php file and no caching is going on - they are).

There are error logs that record pretty much every page access on the site. But they're fairly lacking for session data. I did set PHP to enable all possible errors (error_reporting(E_ALL);) and no errors show up throughout the site for sessions.


Anyway, just to show it's not the code I wrote a couple of quick .php files to test with.

They're located in the http://www.haverdesign.com/test/ directory. First go to /test/setsession.php (of course) then go to /test/index.php. You'll notice it works 100%. However, if you go to /test/ without specifying index.php, and just repeatedly press refresh, you'll notice sometimes it finds the session data and sometimes it doesn't. So odd...

/test/setsession.php


/test/index.php



As I said, I'm 100% convinced it's an issue somewhere on their server. I'm not 100% convinced their "engineering" team will figure out what it is, so I'm trying to figure it out myself, but I'm having no luck.

Oh, and as a side note, this particular host supports SSL for all files, by default. Just change http:// to https://. The interesting thing about this, is, that if I use https://, then the sessions work fine, always. I don't have a lot of knowledge about SSL configurations on a webserver, but I'm wondering if anybody knows where the settings between the http:// and https:// accesses differ and can point to a place to look.

Have you checked Apache's error log?

Unfortunately, I do not believe I have access to that file. =/ I was hoping somebody else might have seen this problem in the past and knew some odd server configuration that was causing it. If the solution is going to take parsing through the server log files, then it's beyond my realm of control for this site. I suppose I will have to sit back and hope the IPower engineering team knows what they're doing.

Set your error log level to E_ALL | E_STRICT. Then go through your pages and see if any warning suggestions pop up, maybe one of your pages is doing something that PHP will let slide by but is causing an effect you dont want somewhere in one of the pages.

Other than that without code theres not much else I can think of. I mean it looks like you are using the plain old vanilla session handler so its not an issue of you using a custom session handling function.

There could be something wrong with the location where session files are saved. I know it's a long shot but it may be worth a try to specify your own directory for session files.

Create an empty directory outside your webroot and make it world-writable. Now add the following to a .htaccess file in your webroot:

php_value session.save_path "/absolute/path/to/your/session/directory"

Well, the support rep I spoke with last night about the issue attempted to do that, but it only caused errors. Following your post, I decided to go ahead and configure the php.ini myself and give it one more go.

I manually set the session.save_path variable through the php.ini file (which defaults to /tmp) to a folder in my home folder below public_html. It appears the sessions are now working perfectly. I guess the rep got the path incorrect somewhere. Thanks for getting me to double check that. :)

I'm still confused as to why they were randomly working so selectively before... Oh well, as long as it's working I've done my job.