Hello!
Caching is invariably the wave of the future. We have worked with many different caching technologies to leverage a website to be able to handle more traffic as well as offering a low cost vector to scale a website without investing in expensive hardware.
We occasionally offer web hosting through our own web hosting infrastructure, but also leverage separate web hosting companies to provide streamlined web hosting services for our WordPress clients.
One web host in particular, that we will not name, recently implemented a shared caching system leveraging Varnish (https://www.varnish-cache.org/) in front of their shared WordPress customers.
This was a great way to accelerate the speed of websites, we thought. We recently ran into a very tricky problem that required a bit of troubleshooting on our part before discovering that Varnish was actually interfering with WordPress’ contact, registration (and potentially other) forms.
We saw that on one registration form, after clicking “Register” , it produced a blank page. Examining the php error logs produced a PHP Fatal error. A function was being called with empty data, causing the white page to be produced.
Why was the function working on our own servers (without varnish) but with Varnish it was producing the blank page? Further to that, this happens only on Chrome, IE and Opera, but not Firefox. After reading an informative post on another site regarding the way Chrome specifically deals with CSRF attempts (Cross Site request forgery), we determined that the following conditions were being met :
1. In Chrome / IE / Opera, a condition is being met or missed that is causing a request to not be fully POST
2. Varnish is changing or stripping a session cookie that is causing this behavior in Chrome / IE / Opera
3. The result is a PHP fatal error and a white screen
The lesson learned (so far) is that the aforementioned browsers protect you from CSRF attempts a bit better than Firefox. If a user tries to inject data into an existing PHP session, you would have more luck with Firefox than any other browser.
How did we see that Varnish was mishandling the PHPSESSSID cookie? We used a Chrome plugin called Fiddler, which is similar to Tamper Data for Firefox.
This Chrome extension allowed us to examine the requests, cookies and other useful data with and without Varnish in front of the WordPress site.
With Varnish
Before hitting “Register” :
PHPSESSID: 7e3ee9fd8973134347053520ef0b6eb0 __utma: 178824928.2040783194.1413905637.1413905637.1413905637.1 __utmb: 178824928.10.10.1413905637 __utmc: 178824928 __utmz: 178824928.1413905637.1.1.utmcsr
After hitting “Register” :
__utmt: 1 __utma: 178824928.2040783194.1413905637.1413905637.1413905637.1 __utmb: 178824928.11.10.1413905637 __utmc: 178824928 __utmz: 178824928.1413905637.1.1.utmcsr PHPSESSID: 99dd9a598d248be93e4fc0f451c5a4e7
Without Varnish
Before hitting “Register” :
PHPSESSID: 99dd9a598d248be93e4fc0f451c5a4e7 __utmt: 1 __utma: 178824928.2040783194.1413905637.1413905637.1413905637.1 __utmb: 178824928.16.10.1413905637 __utmc: 178824928 __utmz: 178824928.1413905637.1.1.utmcsr
After hitting “Register” :
PHPSESSID: 99dd9a598d248be93e4fc0f451c5a4e7 __utmt: 1 __utma: 178824928.2040783194.1413905637.1413905637.1413905637.1 __utmb: 178824928.17.10.1413905637 __utmc: 178824928 __utmz: 178824928.1413905637.1.1.utmcsr
Notice anything? The PHPSESSID cookie hash is retained without varnish. With Varnish enabled, it changes after you hit “Register”. Why Varnish does this would require more diagnosis but unfortunately in this scenario, we are at the mercy of the 3rd party web host and cannot examine the configuration nor Varnish logs. I imagine that the web host would be able to find this out. A simple VCL PIPE for the URI would also be a workaround, though those URIs would be slower obviously.
Very interesting overview of how Chrome, Internet Explorer and Opera behave differently than Firefox. If I were you, I’d use Chrome for more secure browsing š
