I have an intermittent problem with my sign-in/registration system in that some users find that they have to sign in twice. They go to the sign in page, enter their details and rather than being redirected to their own page, have to sign in again.

The sign in process uses sessions and I've monitored what is happening. The session gets passed happily from one page to the next for most users and stays intact when they sign in. All works well.

However, for other users, when they try (and fail) to sign in, the old session gets destroyed and a new one is created. And then they can sign in.

I don't think there's anything unusual in my code and there's no consistency in the platform/browser combination which experiences the problem - except that it is the same people each time who are experiencing it.

This has had me stumped for some time so any suggestions welcome!

The code. Each page starts with:
session_start();

and when a user has signed in I set their data like so:
$_SESSION['name'] = 'Name';
etc. The only time a session_destroy() is used is when the user deliberately clicks on the 'Sign out' link.

    Are the users who are having trouble refusing cookies from your site?

      No - cookies are being accepted. The problem occurs on the sign-in page when the first time these users try to log in a new session is created. On the second sign-in the new session stays active and they can then proceed. It's very strange!

        We'd probably have to see more code.

        When you first set the session variables, do you do a header() redirect? If so, did you try calling [man]session_write_close/man before doing so?

        Also, have the users tried doing a hard refresh? It's quite possible that their browsers are simply caching the page where they land after being logged in.

          Sessions are most often managed by setting a session ID in a cookie.

          When you can't use cookies, you have to propagate your session id by sticking it into every single URL people request on your page. PHP has built-in functionality to handle this (see enable-trans-sid).

          Some software written in PHP (phpBB 2 comes to mind) attempts to locate a session cookie and if it doesn't find one, it tries to add the session id to every link in your page. For example, close all your browser windows and then go here:
          http://www.phpbb.com/community/
          If you have over any of the links, you should see something like &sid=1342aadef23 in the link's address. That's set by PHPBB, the idea being that they want their forum software to work even if you don't have cookies.

          The first time you access any PHP page which might set or look for a cookie, the cookie will not have been set the first time the code in your PHP page runs. That's why you see the session ids at phpBB's site.

          It may be that your system is creating a session (along with a new session id) and then redirecting users to another page using a different session id either in cookie or url and that session id is NOT the one that was in effect when the session was created.

          You might have to either debug your code (if you have a fancy IDE setup) or maybe output logs of your $_session and $cookie values to really understand what's going on. It can be confusing.

            Thanks for the suggestions. I have tried the session_write_close() before the page redirect which I didn't have before but sadly not with any success. The number of people who are suffering with this problem suggests to me that it is not to do with refusal of cookies but possibly more to do with the redirect?

              How are you doing the redirect?

              By default, a session cookie will be set for the host from which the request for the page came. Note that http://mysite.com/path/to/foobar.php and http://www.mysite.com/path/to/foobar.php do not share the same hostname, thus the default PHP session settings would prevent the cookie from one to work on the other.

              session.cookie_domain is the directive that controls the behavior I speak of. One common way to circumvent the null subdomain vs. the 'www' subdomain dillema is to set that PHP directive to a value such as '.mysite.com' (the leading period means the cookie will work on any subdomain - including the null one).

              Otherwise, you'll have to make sure that any redirects/links you make are either relative (technically impossible for header redirects; the 'Location' header requires that you give an absolute URI) or use the values in the $_SERVER array to reconstruct the parts of the URL that the client originally requested.

                The redirect is indeed the culprit and now that I have done this more correctly the session cookies are being maintained. Problem solved.

                Thanks to everyone who has posted on this problem. I am impressed by the expertise that has been shared and the time and thought spent on helping others.

                  Write a Reply...