Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Subclass HTTPBadCSRFToken from HTTPBadRequest and have request.session.c... #1149
...heck_csrf_token use the new exception.
This supports a more fine-grained exception trapping.
There's no possibility of a real namspace collision here, but should the name be something other than HTTPBadCSRFToken to avoid a possible brainspace collision with future http response codes?
Should check_csrf_token() really report itself when raising the exception or am I too used to shell? What about case in the error text?
Should the docs for HTTPBadCSRFToken and HTTPBadResponse state the http error code?
Note that I was unable to get the big exception list in the docs to format properly without the additional blank lines around HTTPBadCSRFToken. There might be a better way.
Note that while I plan to need this in the future I have no immediate need for this feature. This was done more as an exercise in design and hacking the pyramid code than out of present need.
On 10/08/2013 12:57:25 PM, Michael Merickel wrote:
Since it does subclass HTTPBadRequest would you expect
It may take me a few days to get back to do more work