Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)
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.