How does Fastly Caching know when user session has changed in Magento 2 Commerce

Question

BACKGROUND

Magento has the product details page accessible at catalog/product/view/id/{product_id}. It is being hosted on magento cloud so fastly is involved. There are different customer group and each customer group get to see different prices on the product details page. I will usually open two tabs, and on one tab, I will log out of an account that belongs to customer associated with customer group A, then login to an account that belongs to a customer associated with customer group B. Every time I do this, all I need to do is refresh the second tab containing the product details page and the price will change. THIS IS FINE AND THIS IS THE EXPECTED BEHAVIOR

THE ISSUE

I am now in a situation where I need to be able to remove access to a product from a certain customer group in the Magento admin form in the backend and as soon as this is done, a customer belonging to that customer group should no longer be able to access that product page in the frontend upon refreshing assuming the page is already opened in his/her browser. This is proving difficult to do.

Please note that this code works in my development environment and Varnish is also enabled and works in my development environment. Fastly just seem to cache differently IN magento cloud staging environment.

THINGS I HAVE DONE

I have added my own additional tag to X-Magento-Tag by adding a block that implements Magento\Framework\DataObject\IdentityInterface. This Tag is a concatenation of the customer group id and the access status to the product being loaded. If access is revoked, status is 0, otherwise, status is 1.

I have added a before plugin to Magento\Framework\App\Http\Context::getVaryString() and this before plugin also adds the same concatenation of the customer group id and the access status. I believe this is how fastly uniquely Identifies each cached version of a page.

NONE OF THESE HAVE WORKED.

MY QUESTIONS

If fastly works so well when I switch user accounts, why won't it work when additional context need to be factored in?

How do I make fastly check if the user still have access rights to that product page before page is served to web user?

How does fastly know when the current user session have changed? Perhaps I can apply same approach to access revocation.

Answer 1

If fastly works so well when I switch user accounts, why won't it work when additional context need to be factored in?

I would recommend reviewing the HTTP response headers as these will indicate to Fastly how to cache the page.

Typically, for content that is unique to individual users, a Cache-Control response header will be sent with a value that indicates to a downstream CDN that the content should not be cached.

Meaning when you log out of one user account and then log into another, the user's account page will be sending something like Cache-Control: private.

Refer to Fastly's documentation for preventing content from being cached.

How do I make fastly check if the user still have access rights to that product page before page is served to web user?

I would recommend reaching out to support@fastly.com whose customer support team will be able to help debug this for you, but I would imagine this has to do with how Fastly is being instructed to cache the relevant product page.

You should inspect the HTTP response to see if it's being cached by the client (i.e. the user's browser) or by a downstream cache (e.g. Fastly).

You might be able to utilise a Surrogate-Key response header to tag specific product pages and then issue a cache purge for the relevant key.

How does fastly know when the current user session have changed? Perhaps I can apply same approach to access revocation.

Fastly doesn't know when the user's session has changed. Fastly is either instructed to serve a page from its cache, or acquires the content from the origin if either the cache is empty or the content has been marked as being 'private' (i.e. unique to a user).

It's likely that specific pages (such as a user's account page) are sent with a Cache-Control: private response header to indicate the content should not be cached.

I'd suggest reaching out to support@fastly.com for the best approach here, but as mentioned above you might be able to utilise a Surrogate-Key.