[5.x] Prevent protected pages being cached

[duncanmcclean]

This pull request fixes an issue where protected pages would be staticly cached, unless manually excluded in the static_caching.php config file.

Closes statamic/ideas#190.

[daun]

@duncanmcclean Is there a way of reverting to the previous behavior if required? I'm currently relying on caching protected pages in a project. There's a lot of them and the server is really slow :(

[jasonvarga]

We could, but you're aware of the issue this was fixing, right? They become unprotected once cached.

[daun]

@jasonvarga In fact, I wasn't aware. That definitely sounds like something to avoid at all cost. I need to check real quick if the site in question requires a fix on our end in this case 🤠 Looks like it.

The best strategy for caching protected pages would probably be namespacing the cached pages by the user or login state, a bit like the {{ cache scope="user" }} tag would.

[jasonvarga]

Definitely. I'm sure there's an feature request open already to support that.

[duncanmcclean]

Definitely. I'm sure there's an feature request open already to support that.

There is - go and give statamic/ideas#1234 a 👍.

[simonworkhouse]

This is a particularly nasty breaking change for us and it did not become apparent until production response times started triggering alerts.

We would greatly appreciate the ability to configure whether or not to allow caching for "protected" pages.

[duncanmcclean]

So you'd prefer for protected pages to be unprotected after the first visit?

[simonworkhouse]

Not by default, no, but at least a mechanism for one to control whether or not they should be, ideally controlled by the static cacher itself.

In our use-case we have a custom static cacher which utilises cache tags and is aware of which version of the cached response to deliver to the user.

Implementing a clean work-around would be simple enough if it wasn't for methods in the Statamic\StaticCaching\Middleware\Cache middleware having been declared private. I'd also recommend reconsidering the use of private as it's very common for middleware to be extended.

[duncanmcclean]

Implementing a clean work-around would be simple enough if it wasn't for methods in the Statamic\StaticCaching\Middleware\Cache middleware having been declared private. I'd also recommend reconsidering the use of private as it's very common for middleware to be extended.

If it would make it easier to workaround, then feel free to submit a PR to make it public or protected instead.

In an ideal world, we would add proper support for caching protected pages but we haven't got there yet.

This PR just fixes it for now as it's a potential security issue for some.

[antonhedling]

Just want to comment and say that this change absolutely murdered our prod due to the fact that we had:

protect: 'null'

stored in most of our .md-files, since I guess this is how it was stored back in the day. This resulted in a string "null"-value that was considered truthy and therefore no page was cached. Just in case someone else had to spend hours debugging performance issues lately...

[simonworkhouse]

I have submitted a PR that adds support for allowing protected pages in the static cache via configuration and/or custom protectors #11212