This guide is for the older version of Magento platform. We recommend you to use the latest version of Magento.
Whenever Magento Inc. releases a new version (major or minor) of the Magento platform, every Magento developer (novice, intermediate, or expert) prays to God to have mercy on our souls. Every time a new version of Magento is released, it is a maze and many find themselves in such a situation where they are unsure if they should upgrade or not. Today, we’ll discuss the dilemma of Magento Varnish Cache.
Magento (after becoming the independent company) made some major changes in effect. Security became the prime concern and they started working on it. In versions prior to 184.108.40.206, there were some security issues which were fixed. From the documentation, the following are the major issues that were fixed:
- Improved the password hashing algorithm
- Resolved issues that could have resulted in Cross-Site Request Forgery (CSRF) in the web store
- Resolved potential issues when issuing Return Materials Authorizations (RMAs)
- Resolved a session fixation issue when registering a user with the web store
- Resolved a cross-site scripting (XSS) issue reported in CE 220.127.116.11
- Fixed the security settings for the frontend cookie to protect user sessions
You can find the complete list here.
Magento says “bye” to Varnish
There is nothing such as free lunch in this world. The same principle applies to the Magento Community Edition which is free-to-use.
So, what is the cost here? Sadly, it is the absence of Varnish Full Page Caching.
Magento 1.8.1 (and above) included a new “form_key” parameter which was added to POST requests to prevent XSS attacks. This new parameter causes troubles for Varnish. The product page is cached with the first session of the form_key visiting the website and the other visitors cannot pass CSRF check because it does not match with their form_key session.
Magento 1.8 Form Keys
Magento’s backend had these form_keys that prevented XSS attacks all along, but after 1.8.1, it was now introduced in frontend as well. Everyone must be guessing why? Pretty much the same reason, i.e. to protect against form submission from another website using your browser (aka XSS).
By adding a unique key to each form or to each link that generates an action on the server, the URL or form content becomes no longer predictable. Therefore, it becomes impossible for an attacker to improvise. The form key is stored in the session data and validated upon submission to the server. If they don’t match, you get a form key error.
Our good ol’ Magento Varnish caches everything it gets its hands on, so it caches the form_keys as well when the first time the page is visited. When it reaches for the same page again with the old form key that is already cached, the CSRF check will reject the request saying: “You have the wrong key.”
Now, the next thing that comes up in a developer’s mind is to tell Magento Varnish not to cache form keys. That is correct, but it is not as simple as it seems because the form key is not a separate block which can be excluded easily. It’s part of top level pages you will want to cache, like Categories and Product Details—and even the homepage if it contains “Add to cart” links.
This makes it pretty hard for most popular free Varnish plugins (like Turpentine, Page Cache, etc.) to work with it.
What’s the problem?
Let us try to replicate the issue for better understanding
We have a sample store with Magento 18.104.22.168. I opened the same Product page in 2 different browser sessions, the first is Chrome and second is the Incognito Mode of Google Chrome. Both products are added without Varnish Full Page cache plugin and as you can see we have 2 different frontend cookies with 2 different form _keys.
Now, we enable Varnish and add the same product, in the same manner, we get:
Here you can see the form_key is same because it was cached and it was posted with form data resulting in failure of CSRF check by Magento. The request is considered as void and no product is added to cart.
Four ways to configure FPC or Varnish with Magento 1.8.1 and above
In the following paragraphs, I would tell you the way through which Magento, Varnish will work with your online store.
A Quick Fix
There is an addon available or I would say a quick fix. What it does that it simply removes the CSRF check and form_keys, making it same as prior to 22.214.171.124 releases. However, I will not recommend that as there is no point in using a new Magento store if you are not availing its security features. Still, this is a small workaround for those who want to take the risk.
Using the FPC Extensions
There are a lot of extensions now who claim to have solved this problem using their own techniques.
This one is very simple and judging by the demo we would not have to add any additional block on the default installation. This one generates cache page manually by executing it via Dashboard > System > Full Page cache > Store Views > Generate.
Manual cache generation must be required after making changes to the product. This raises a question about the load it will create on the server if the product numbers are high.
Compatibility: Magento Community Edition (CE) 1.7.x – 1.9.x
The demo can be found here. (you will be automatically logged in)
This is one of simplest but fastest Magento Full Page Cache extension I’ve found. Plus, this one does not require hard studies, the configuration is simple and easy to handle. Just read the installation guide.
Compatibility: Magento CE 1.4.x – 1.9.x
This one is highly configurable, both for the primary and secondary cache. It has great reviews about increasing site speed. Again, this one needs hole punching and with a custom theme, this can be the pain to configure.
Compatibility: Magento CE 1.4.1 and higher
This one looks good and has a good list of features. However, one disadvantage is that the installation of this extension requires editing index.php file.
Compatibility: Magento CE 126.96.36.199 – 188.8.131.52
For best performance, I will prefer one of the latter two.
The Lesti FPC
Lesti is a great plugin that helps in resolving this issue. The best part is that it’s free. But, you need to define which blocks you don’t need to be cached. A full explanation can be found here.
Nitrogento is a plugin that solves everything (almost). Sadly, like many great Magento plugins, it is not free but you can get 30 days free trial to check the performance, it handles the form_keys issue and improves the store speed as well.
It is pretty easy to install and it has no difficulty settings. So, there is not much trouble. You can get Magento Varnish hits by simply enabling it. Plus, the cart also works like charm.
I did a few tests before installing Nitrogento. Here are the results that I got.
GTMetrix shows this:
Here is the result from Pingdom:
After installing, Nitrogento shows small changes on GTMetrix:
However, Pingdom shows good improvement. Notice this. Your website will be now 96% faster. This means you will be serving more visitors in less amount of time:
Keeping up with the latest Magento trends, Cloudways comes up with the latest blog post on how to make Varnish cache work with Magento 1.9.x stores.
Here, I have given four different solutions to this problem. I did this because Magento hosting is like an art. A single solution rarely fits all. Therefore, I would suggest that you test it out for yourself. If you know a different solution, do let us know in the comments section below.
Boost Your Magento Store Performance by 5x Times & Maximize Your Sales
Our fastest Magento hosting can help you in growing your business revenue by 500%
Fayyaz is a Magento Community Manager at Cloudways - A Managed Magento Hosting Platform. His objective is to learn & share about PHP & Magento Development in Community. Fayyaz is a food lover and enjoys driving. You can email him at firstname.lastname@example.org