{"id":8590,"date":"2017-11-20T04:00:50","date_gmt":"2017-11-20T08:00:50","guid":{"rendered":"https:\/\/blog.litespeedtech.com\/?p=8590"},"modified":"2017-11-20T04:00:50","modified_gmt":"2017-11-20T08:00:50","slug":"magento-monday-litemage-cdns-and-tokens","status":"publish","type":"post","link":"https:\/\/lswp.store\/index.php\/2017\/11\/20\/magento-monday-litemage-cdns-and-tokens\/","title":{"rendered":"Magento Monday: LiteMage, CDNs, and Tokens"},"content":{"rendered":"

\"\"<\/p>\n

Welcome to the first installment of Magento Monday<\/a>! We\u2019ve enjoyed bringing you WordPress Wednesday<\/a> every week, and so we thought it would be fun to also share some helpful Magento and LiteMage<\/a> tips here sometimes.<\/p>\n

Let\u2019s kick off this series by talking about Content Delivery Networks, how the custom CDN cache rules you have defined may be breaking your Magento 1.x store, and what you can do to fix the problem.<\/p>\n

Note: This particular issue is only a Magento 1 issue. It does not apply to Magento 2. <\/em><\/p>\n

It\u2019s all about the Tokens<\/h2>\n

Magento 1.x uses a session variable called form_key<\/code> as a CSRF token to prevent CSRF injection<\/a>. The form_key<\/code> value is stored in the user session and is unique for every user. When a shopper adds a new product to the cart, or a new item to compare, Magento looks for the form_key<\/code> token in the dynamically-generated HTML, and uses it in the validation process.<\/p>\n

If there is no caching solution enabled at all, then this process works.<\/strong> It\u2019s slow and painful, but it works.<\/p>\n

If LiteMage is caching the dynamic pages, then this process also works.<\/strong> LiteMage is smart enough to know that it must use ESI to \u201chole-punch\u201d the correct unique form_key<\/code> token value for each user into the generated HTML, so that it may be used for validation.<\/p>\n

If a CDN is caching the dynamic pages, then this process falls apart.<\/strong> Content Delivery Networks are not smart enough for hole-punching. They cache only one version of the page, which means they save only one form_key<\/code> token for every shopper to share. This can\u2019t possibly work, and validation is broken.<\/p>\n

We recommend that you turn off all caching of dynamic pages in your CDN. CDNs are great for static content, like CSS, JavaScript, and image files, so by all means, leave that type of caching enabled, but let LiteMage handle the dynamic page-caching duties<\/em>.<\/p>\n

Diagnosing and Fixing the Problem<\/h2>\n

How can you tell whether your page is being served from CDN cache or LiteMage Cache? Take a look at the Response Headers.<\/p>\n

What you want to see is something like this:<\/p>\n

\n\nX-LiteSpeed-Cache: hit,litemage\n\n<\/pre>\n
This shows that LiteMage is in control of caching the page.<\/p>\n
If you see headers like the following:<\/p>\n
\n\ncache-control:public, max-ago=14400\ncf-cache-status: HIT\n\n<\/pre>\n
then the CDN (in this case Cloudflare) is doing the caching.<\/p>\n
Here\u2019s how to stop that from happening:<\/p>\n
From the Magento admin area, navigate to System > Configuration > General > Web<\/strong> and open the Unsecure<\/strong> and Secure<\/strong> sections.<\/p>\n
\"\"<\/p>\n
While it may be easier to just set Base URL to the CDN\u2019s address, and let the CDN sort out what content should be served from where, doing so is highly inefficient and will slow down your site. Why send a request to the CDN only to have it bounced back to your own site for fulfillment?<\/p>\n
Setting it up properly in this section ensures that requests are routed to the proper locations right from the start, with no time wasted with unnecessary travel back-and-forth.<\/p>\n
Set the Base URL<\/strong> to your site\u2019s address, not<\/em> the CDN\u2019s.<\/p>\n
The Skin<\/strong>, Media<\/strong>, and JavaScript URL<\/strong>s refer to static content, and those may point to your CDN.<\/p>\n
A note about the Unsecure<\/strong> section: Technically, you can use http:\/\/<\/code> in these fields, but with LiteSpeed\u2019s emphasis on HTTP\/2 and QUIC, you have the ability to use https:\/\/<\/code> everywhere. These days security is a big deal, so why wouldn\u2019t you use it?<\/p>\n
So, Why Don\u2019t CDN Cache Rules Work?<\/h2>\n
If you know about Magento 1.x\u2019s session cookies (frontend<\/code> for HTTP and frontend_cid<\/code> for HTTPS), you may have tried to use them to configure the CDN\u2019s cache rules as follows: if there is no session cookie, it means the user hasn\u2019t started shopping yet, and the page can be cached by the CDN. If there is a session cookie, then the request must be sent to the Magento backend.<\/p>\n
It\u2019s a clever idea, but unfortunately it doesn\u2019t work, and this is why:<\/p>\n
The form key is irrelevant while the user is simply browsing, and so it seems fine to serve the page from CDN cache. However, as soon as they try to act (add an item to the cart, or to compare), the form key becomes important. And because of the fact that they are performing that first action from the cached page, they will be looking at the cached form_key<\/code> value instead of a form key that’s been generated specifically for them<\/em>. As a result, the action will fail.<\/p>\n
If the user reloads the page, the CDN recognizes that they now have a session key, and so their request hits the backend, the correct form key is generated, and they are able to shop normally.<\/p>\n
The problem works itself out on the second attempt, but the damage to user experience has already been done.<\/strong> Some shoppers will reload and keep going, but others will leave after the first error. Can you afford to lose those customers?<\/p>\n
\"\"<\/p>\n
Even if the session cookie idea had<\/em> worked, it\u2019s hard to see what would be gained from having the CDN handle the caching of that page. LiteMage, which was built specifically for Magento, can manage your shop\u2019s cache in a much more efficient way than a Content Delivery Network can. As we\u2019ve already seen, LiteMage can punch holes for private content, making it possible to store a single copy of the page in public cache, and then serve it with the personalized information in the punched holes.<\/p>\n
With the CDN in charge, users who are actively shopping cannot benefit from caching, but with LiteMage, they can.<\/strong><\/p>\n
Additionally, LiteMage can take advantage of tag-based purging, making sure that all of the necessary pages (and only<\/em> the necessary pages) are purged when a product is updated.<\/p>\n
If you are running LiteMage, it\u2019s best to let LiteMage handle all of the page-caching that it was built to handle. Your Content Delivery Network can easily deal with the rest.<\/p>\n
—<\/p>\n
Have some of your own ideas for future Magento Monday<\/a> topics? Leave us a comment!<\/p>\n
If you enjoyed this, here are a few other things you can do:<\/p>\n