Now that you can have long lived sessions (see MDL-65812) there is an increased risk that a sesskey might be compromised. A nice mitigation is that the sesskey could rotate every N minutes (probably ~1 hour) and that confirm_sesskey() might honor the previous X keys (probably ~2-3)

There is two ways this could be implemented:

1) We store a list of sesskeys and generate a new one every N minutes, and we honor sesskeys which are within a certain age. A downside to this approach is we have to persist things often to the session and it keeps changing often.

2) Instead of storing a list of keys, we internally store a single seed for the sesskeys in the session and then when you get the sesskey we actually generate it on the fly using the seed, similar to how pseudo random number, or a how HOTP passwords are generated. Then it is very easy to confirm any key is valid by cycling back through N time periods and checking them without actually storing them. Under this approach the session state never needs to change which has lots of other performance and scaling benefits.

On top of this, it would be better UX if when a user submits an action and the sesskey was valid but isn't any longer is shows a nice message and ask them to confirm the action which then uses then the latest key.

If you have a fairly relaxed MOOC style site where you might never logout, or perhaps have a 1 month session expiry then you might want to rotate sesskeys every day. If you have a more secure site with say a 4 hour session timeout and very high compliance you could ramp down the session key regeneration to say 5 minutes.