For "sudo" We could add something like "auth::force_authenticate" which would grant a short dated nonce to validate an action; it would not really even be that hard to implement but of course you would have to go through the code and apply it.
Jonathan's trick is essentially a nonce that expires when the server restarts. The downside is that relying on a shared
variable like that means that if you have multiple frontend
servers you need to sync these (whereas something signed with a random session cookie + a server secret + user_id would not need to be synced between the front ends, would survive server restart, could be made to expire by adding an expiry to the signed key, and would be equally secure).
Oh, one issue with making all the pages that do actions only accept POST is that if your login expires the whole redirect
for registration relies on being able to do redirects to
propigate state which of course result in GETs. That means if you fill out a form, send a post, it does a redirect to register with a return_url; signing in then does a redirect to the return_url which (because the target URL only accepts posts) fails.
It also means single page add-edit screens would need to
be reworked since the initial link to the page would be a
GET (i.e. you could only check it was a POST when you really went to modify state).
Anyway, there are a bunch of cases like that where the assumption is that GET == POST and fixing it in a way that
is both secure and not horribly unpleasant to use is not-trivial I think.
