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:

    Domain: mycompany.com
    Session path: /tmp/
    Webserver user: mycompanycom

    Domain: support.mycompany.com
    Session path: /tmp/
    Webserver user: nobody

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/!):

    mkdir /tmp/support.mycompany.com
    chown nobody:nobody /tmp/support.mycompany.com

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

    php_value session.save_path '/tmp/support.mycompany.com'

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

    rm -f /tmp/sess_*

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.

Hello, future.

Published

Write a Comment

Comment

  2. 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.

    Reply to Robert

    • 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.

      Reply to Raam

  3. 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!

    Reply to Shane

Related Posts