> My feelings on this are:

> 1. If code blocks are generally useful, it should be in web.py and not
> a cookbook page
> 2. CSRF is generally useful -- web.py should have CSRF protection
> 3. The right way to add CSRF to web.py is to write up a spec and run
> it by me and a web security expert

> web.py's policy on security is generally "secure by default" but it'd
> be extremely backwards-incompatible to start requiring CSRF on all
> forms. I'm not sure what to do about this. One idea is to have a flag
> on web.application that specifies CSRF or not and then have an opt-out
> on...I guess web.input? And maybe eventually the flag could be made
> default, after enough warning. Another is to just add a new name for
> web.input (web.inputs?) and encourage people to use that instead.
> That's probably the best idea.

> Then there should be two functions built into templetor, one that
> returns a hidden input with the token and one that just returns the
> token itself.

> The main security question is: what's the token? The cookbook page
> uses a random number stored in the session. I hate sessions so I of
> course I don't like this. I'd prefer some sort of HMAC of the browser
> fingerprint, but I don't know if that's secure. This is where the
> security expert comes in. I'll ask around about this.