Request tokens could be regularly pinged to prevent staleness

[MichelleBlanchette]

I've realized that security tokens could fail to go stale if a malicious actor sets up a cron job to repeatedly hit a public endpoint (or simply web crawlers keep hitting it). This is because a request token's last_accessed datetime is updated whenever it is loaded from the database, which is what determines whether it should be expired or not during staleness checks.

https://github.com/PurpleTurtleCreative/completionist/blob/2255020e09ba8cd78ffce3093f766437f429cb11/src/public/class-request-token.php#L566-L570

Instead, request tokens' last_accessed should only be touched when they are saved. They are only saved during securely authorized actions but can be read/accessed publicly.

The original idea was that request tokens shouldn't expire due to HTML caching preventing the Request_Token::save() calls that actually update the last_accessed datetime. There could be a situation where the HTML is cached, the request token is expired, and then the frontend requests fail since the token no longer exists. That is likely to be a rare edge case, though, and I would just suggest users exclude Asana project embeds from their caching—which isn't actually fair because they could have an embed displayed globally across their site. Instead, the best suggestion is that they should filter the staleness duration to be longer than their caching cycle. That way, the request token will outlive their HTML cache so it can be hit again from the HTML cache expiring.

[MichelleBlanchette]

Additionally, I've added action hooks for when request tokens are deleted, so a user could purge their HTML cache whenever request tokens are deleted. They don't know exactly what pages are affected or which tokens were deleted, but it can still be a useful alternative.