This project is read-only.

Admin User Edit Mode - Sent to CDN (Akamai) Cache

Topics: Administration
Nov 17, 2012 at 2:59 AM
Edited Nov 17, 2012 at 3:01 AM

We had an interesting thing happen today.

One of our users was signed in as Admin, and then went to the home page.  Akamai (our CDN), must have had expired cache for the home page, and at that moment CACHED the home page as a signed in Admin sees it - with all the 'Edit' buttons showing.

Akamai then propagated that version of the home page to its worldwide set of front end caching servers.

So, every anonymous user saw the 'Edit' buttons on the home page.

Ctrl-F5 doesn't help because: a. Most people wouldn't do that anyway.  b. Akamai ignores that and DOESN'T go all the way back to origin to get a fresh version.  c.  Akamai, like all CDNs is distributed so even if it did work it wouldn't then load that version into cache.  d.  It's possible that the version with the Edit buttons would just get re-cached.

One way I can think of "fixing" this is to overlay the 'Edit' buttons via Ajax (not initial page load).

Looking for ideas...



Nov 17, 2012 at 3:01 AM

Did you talk to Akamai? Don't they have a setting to not cache authenticated requests? (which should obviously be the default)

Nov 17, 2012 at 5:44 AM

I can check. I'm not sure how Akamai would know if it's authenticated. But we may have other pages that the user is authenticated and we would want Akamai to cache those. It's just the ones with Edit overlays I'm concerned with.

Nov 17, 2012 at 6:06 AM

Easy: authentication is in headers. You can vary by those headers.

But in general, caching headers should be set to tell the world whether something is ok to cache or not.

Aug 22, 2013 at 4:45 PM
We are facing the same issue with Akamai and we will contact them and ask about that issue.
Did you come up with any solution?
Aug 27, 2013 at 8:49 PM
We did not come up with a workable solution, so we turned it off. The problem is that we don't set headers per user role, so Admins and non-Admins will get the same cached page each time. With full page caching in AK it makes it tricky because even an Admin user does get the page from Cache. As Bertrand said, we could do header inspection at AK and go back to origin if a header is set, but we don't necessarily want to disable caching just because you're authenticated. We have other reasons for signing in beyond just dashboard and want the users signed in to have a cached experience. It just gets to be too complicated and fragile to mess with headers depending on what type of access they have.

I think the best idea is to load the 'Edit' overlays as an ajax request if the user has that permission. We haven't gotten around to coding this yet.