Great job on seamlessly setting up Varnish!
We're utilizing the default.vcl file with the settings shown in the attached screenshots, and everything is working smoothly.
However, we've encountered a minor issue related to admin actions. When an admin finishes editing and logs out, navigating to any page they modified still displays the admin features (admin menu, edit links, etc). A simple refresh resolves this, presenting the correct view without the admin elements. Additionally, attempting to click on any edit links leads to the expected "access denied" page.
We're curious if there's a way to address this behavior proactively. Is it possible to force the invalidation of all pages accessed by an admin while logged in, ensuring they display correctly when logged out?
Any assistance or guidance on this matter would be greatly appreciated!
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | SCR-2025-04-02.jpg | 76.22 KB | glynster |
| #8 | SCR-2025-03-31.jpg | 55.89 KB | glynster |
| Xnip2024-01-05_10-49-26.jpg | 124.32 KB | glynster | |
| Xnip2024-01-05_10-48-31.jpg | 87.6 KB | glynster |
Issue fork adv_varnish-3412639
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
glynster commentedHere is some additional information:
This issue occurs on macOSX with Chrome, Safari, and Arc. Interestingly, it does not manifest in Firefox. Firefox behaves as expected. I'm uncertain if this detail helps in identifying the underlying issue.
Comment #3
glynster commentedAdding the following to the default.vcl resolves the issue:
We have tested this on Arc, Chrome, FireFox, and Safari and it works as expected.
Perhaps we are doing something wrong initially. Would love some feedback!
Comment #4
glynster commentedAfter much testing this is what we ended up with:
This keeps admin/logged in completely uncached. Our main reason for this is to make sure the admin menu never shows logged out and also to make sure no data is lost with forms. Most of our clients prefer to roam their sites and edit as they go.
Comment #5
summit commentedHi, was #4 the complete solution, or #3 and #4 together?
greetings,
Comment #6
glynster commented@summer here is the complete varnish vcl we are using successfully.
Comment #7
summit commentedHi, Thanks! I have asked my hosting provider to upload your .vlc without changes, I let you know if it succeeds for us as well.
And do you know how I can see if Varnish works? Right now I do not yet see any difference?
Thanks! Greetings,
Comment #8
glynster commentedTo see if varnish is working you need to review the network tab, select the page and view the headers. Search for caching like attached.
Comment #9
summit commentedHi, the attached image https://www.drupal.org/files/issues/2025-03-31/SCR-2025-03-31.jpg, looks like there is no varnish caching, right?
greetings, and thanks for the quick reply!
Comment #10
glynster commentedCorrect on the screenshot I grabbed that was an admin page. Here is a varnish hit.
Comment #11
shumer commentedThanks for the detailed report and the proposed solutions! This is a really good catch.
I looked into this and I believe the root cause is actually browser-level caching, not Varnish. Here's my reasoning:
Why Varnish is not the problem here
Varnish correctly separates cache entries by user role via the X-Bin header in vcl_hash. When an admin views a page, it's cached under
X-Bin = "role:<admin_hash>". After logout, the same page is served from a different cache entry underX-Bin = "role:anonymous". These never collide.Why it works in Firefox but not Chrome/Safari/Arc
The module sets
Vary: X-Bin, Cookieon responses, which should tell browsers to invalidate their local cache when cookies change (i.e. on logout). Firefox strictly respects this, so it re-fetches the page when cookies are removed. Chrome and Safari are more lenient with Vary: Cookie interpretation, especially when cookies are deleted rather than changed. They may serve a stale copy from browser cache without revalidating (this explains why refresh could help to see updated page).The key issue is that the module doesn't set an explicit Cache-Control header for authenticated responses by default. Drupal core sets
max-age=0, public, which some browsers interpret as "you can cache this, just revalidate", and then don't always revalidate properly on cookie removal.Why the proposed solutions are too aggressive
Both approaches throw away the Varnish-level cache to fix a browser-level problem.
My proposed fix
Since Varnish uses X-TTL for its TTL (not Cache-Control), we can safely override Cache-Control in vcl_deliver for authenticated users without affecting Varnish caching:
This tells browsers to never cache authenticated pages locally, while Varnish continues to cache them normally via X-TTL. After logout, the browser is forced to fetch from Varnish, which correctly serves the anonymous version.
Does anyone want to try the solution so we can have a proof that it works?
Comment #13
shumer commentedComment #14
glynster commentedTested and confirmed: your diagnosis is correct. We kept X-Bin role-based caching, avoided hash_always_miss/blanket uncacheable,
and added this in vcl_deliver for authenticated bins:
Result: logged-in/admin requests remain uncacheable/pass-through, anonymous requests still HIT in Varnish, and stale admin UI
after logout is resolved in Chrome/Safari/Arc in our testing.
Comment #15
shumer commented