A69411ab20797e321be7f1950c4a1dcd147a8099
By:
mar2y

Why Are PHP Cookies Not Being Created (but are with Wordpress)?

January 9, 2017 1.4k views
PHP LAMP Stack Ubuntu 16.04

I have a 'Ubuntu Wordpress 4.7 on 16.04' droplet (1 click install). PHP-FPM and Varnish have been added. I've created an apache conf for the main domain and another for the blogs subdomain, and deactivated the default conf. I've edited my local hosts file to point to this server for testing.

Everything appeared to be working fine, until I hit a strange problem with cookies. I can login and use Wordpress just fine - cookies are created as expected, including the PHPSESSID cookie.

But if I create a simple session_start() test script, the PHPSESSID cookie is not created (and the session doesn't persist).

<?php
session_start();
$_SESSION["favcolor"] = "green";
echo $_SESSION["favcolor"] . "<br>";
?>
<?php
session_start();
print_r($_SESSION);
?>

The same script works when tested locally. I'm trying it on the server in the same directory as Wordpress. And I can see the session is being created on the server in /var/lib/php/sessions. But no browser cookies. Same if I test using setcookie(). Same if I test under the main domain.

At first I suspected a conflict with Varnish, but I've temporarily bypassed it while testing (using 'return (pass)' as the first entry in vcl_recv).

Also intriguing is that if I let Wordpress create the PHPSESSID cookie by logging in. Then my session test script DOES work. Until I delete the PHPSESSID cookie, then it won't create it.

What am I missing? Why is this working with Wordpress but not with a regular php test script..?

2 Answers

@mar2y

If you use your Droplet Public IP and visit your Droplet using only the IP instead of using the local host file modification for forced routing/resolution, does the cookie set?

  • Thanks for the suggestion. I reactivated 000-default.conf, and tried via the IP directly - but same result. Whilst I was there I also tried disabling PHP-FPM, but same result.

@mar2y

In that case, what I would do is disable Varnish entirely (as it shut it down) and then temporarily set up Apache to be the primary handler for requests without Varnish sitting in front.

If direct access isn't working, my thought would be that there's something wrong with the VCL or misconfiguration elsewhere that is preventing it from sticking.

While it may not be a major issue now, if it's not allowing even the most basic of sessions, it may lead to issues later on down the road when you're running production.

If that works, we know it's an issue with Varnish. If it doesn't, I'm a bit perplexed as baring Varnish, even a basic installation of Apache + PHP should handle sessions without any issues.

  • Yup, you're on the money. I stopped varnish, and put apache back on port 80, and sessions work normally again.

    So then I reactivated varnish but went back to the stock default .vcl - and sessions still work. Put my custom vcl back in, and cookies break.

    Grrr. Lesson learnt - return (pass) as the first entry in vcl_recv is NOT a guarantee of bypassing varnish.

    At least I now know where to look. Back to debugging my vcl :-)

    Thanks.

Have another answer? Share your knowledge.