on Technology

PHP Session Permission Denied Errors with Sub-Domains and IE7 or IE8

I encountered a strange problem with IE7 and IE8 where if I visited example.com first and then visited sub-domain.example.com, Apache would return Permission Denied errors errors when trying to access the PHP session files for sub-domain.example.com.

After some investigation, it appears this is a problem with the way IE7 and IE8 request session data from Apache, or possibly because IE7 and IE8 have a non-standard way of announcing the domain they're requesting session data for.

Here's my scenario:

I'm running Apache 1.3 with two domains, each has their own account with their own users:

Here is what happens during a normal visit with Firefox/Safari/Chrome:

  1. I visit mycompany.com and session file is created in /tmp/ owned by the user mycompanycom
  2. I then visit support.mycompany.com, and second session file is created in /tmp/ owned by user nobody
  3. Apache doesn't get confused and the correct session files are returned

However, here's what happens during a visit with IE7 and IE8:

  1. I visit mycompany.com and a session file is created in /tmp/ owned by the user mycompanycom
  2. I then visit support.mycompany.com and, instead of creating second session file in /tmp/ owned by the user nobody as you would expect (and as happens when using Firefox/Safari/Chrome), Apache tries to return the session file for mycompany.com.
  3. The session file for mycompany.com is owned by the user mycompanycom, so the web server, running as user nobody cannot access it. Permission is denied.

I searched Google for a solution and came across this question on StackOverflow. Several users suggested creating a separate directory in /tmp/ to separate the stored session data for support.mycompany.com from the session data for mycompany.com and then telling PHP to store all session data for support.mycompany.com in the new directory. This worked perfectly!

Here's what I did. First, create the new session directory (Note: Make sure the new directory resides inside /tmp/!):

I then added the following to an .htaccess file in the root web directory for support.mycompany.com:

And finally, I removed all existing session data in /tmp/ to ensure the new session path would get used immediately:

And that's it! Now IE7 and IE8 work properly because when visiting support.mycompany.com, IE7 and IE8 do not accidentally find session data for mycompany.com and try to use it.

I'm fairly certain this problem has to do with how IE7 and IE8 request session data from Apache. They probably first request session data for mycompany.com and THEN request session data for support.mycompany.com, even though the latter was the only doman entered in the address bar.

Leave a Reply for Shane Labs Cancel Reply

Write a Comment

Comment

  1. I just had this exact problem with a clients’ dedicated server running cPanel / WHM. One of their accounts is domain.com and another. separate account is subdomain.domain.com. Everything worked great in all browsers on Mac and PC. The only time is would not work is when you were in IE7 or IE8 and you went to domain.com FIRST, then went to subdomain.domain.com.

    I could not figure out why it worked fine in all other browsers except IE. Luckily, I found this post.

    Almost any time I have some weird problem relating to web sites, it always turns out to be Internet Explorer. In my experience, this has been the case for the past 12 years.

    • I’m glad this helped, Robert! I remember how puzzled and frustrated I was when I had this problem and couldn’t find any explanation on the web. I can only imagine what a relief it must’ve been to find someone with the same problem and a solution! 🙂

      I haven’t touched IE in so long (I don’t even know what version they’re on now) but I’m so happy that more and more people know about and use more standards-compliant browsers like Firefox and Chrome.

  2. Thanks for the analysis on this – had the same problem happening and you were the only one that pinned it. Although your solution will work, we’re going to set up a redirect so that non-www traffic just gets redirected to www traffic, which should avoid the issue.

    Thank you Raam!