I'm developing a Drupal 8 project which interacts with an external API. This API handles user authentication, completely bypassing the Drupal user system. This means that logged in API users are treated as anonymous Drupal users.

I have created a module that utilises the PrivateTempStore to store user sessions. This works as expected. However, what I am unclear about, is the best practice as far as utilising the Internal Dynamic Page Cache and Internal Page Cache modules.

At the moment, any user session sensitive blocks or pages that my module outputs are set to have a maximum cache lifetime of zero - to ensure that, for example, the user's account page is not served from the cache.

Is this the correct approach, or would I be best at least disabling the Internal Page Cache module - which specifically targets anonymous users?

The site will be hosted on the Acquia platform, so Varnish will likely be utilised.
For that same reason, is it better to disable one or both of the Drupal caching modules?

  • Using an external system for authentication is fine enough, but I don't quite understand why you don't store whatever you need to store in the session anyway? You can do that for "anonymous" users too, the session storage doesn't care about that. Contrib modules like Poll and Flag do that too. You should get a bunch of things for free then, like disabling page cache and varnish should then also work without special configuration (I assume acquia has it pre-configured to respect the default drupal session cookies, haven't used that myself yet, I'm a platform.sh user :)). – Berdir May 18 '16 at 18:51
  • That said, you can implement your own Request/ResponsePolicy implementation. implementation to opt out of page cache in a more generic way. the basic auth module does that for example. Also not quite sure how you handle authentication, drupal kind of has a pluggable authentication system that you could hook into (not an actual hook ;)), so that there's still something like a "current user". Sounds like you might hit some limitations there, especially with other modules if they expect a full user entity there. – Berdir May 18 '16 at 18:55
  • @Berdir - I'm a bit confused by your first comment - I am using the Drupal user.private_tempstore service to store the session data? The issue with caching generally is that, as far as Drupal is concerned, an anonymous user is just that - anything that has been cached for an anonymous user will be served (if the cache has not expired) to any other anonymous user. That's obviously by design. – user34185 May 19 '16 at 9:07
  • Interestingly, in order for anonymous user session data to persist correctly, you need to use a bit of a hack and directly set something into the session (as detailed here - sitepoint.com/how-to-build-multi-step-forms-in-drupal-8) - if you don't, Drupal's session garbage collection will remove your anonymous user data on subsequent requests. – user34185 May 19 '16 at 9:09
  • Your assumptions are not correct. page caching isn't anonymous vs. authenticated. It's having a session or not. And private temp store requires a session as well. So unless you have a ton of data to store (that's what it is for, storing things like views being edited), just put it in the session. Then you also don't have to worry about your session not being kept. – Berdir May 19 '16 at 18:51

Private TempStore always generate Anonymous Session. That means If you are using any Caching Layer for your Application it always break. either in Acquia or other platform.

May be you can use Browser LocalStorage for saving data and sync it when its required. it will help you to cache your pages.

In Acquia, cookie based cache variation Generation possible so you have to create cookie and based on that value you can generate cache tags.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy