Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subclass HTTPBadCSRFToken from HTTPBadRequest and have request.session.c... #1149

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
3 participants
@kpinc
Copy link
Contributor

commented Oct 8, 2013

...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.

Karl O. Pinc
Subclass HTTPBadCSRFToken from HTTPBadRequest and have request.sessio…
…n.check_csrf_token use the new exception.

This supports a more fine-grained exception trapping.
@mmerickel

This comment has been minimized.

Copy link
Member

commented Oct 8, 2013

This is not an http exception. I'd expect to see a CSRFError or BadCSRFToken exception in pyramid.exceptions that subclasses HTTPBadRequest.

@kpinc

This comment has been minimized.

Copy link
Contributor Author

commented Oct 8, 2013

On 10/08/2013 12:57:25 PM, Michael Merickel wrote:

This is not an http exception. I'd expect to see a CSRFError or
BadCSRFToken exception in pyramid.exceptions that subclasses
HTTPBadRequest.

Makes sense.

Since it does subclass HTTPBadRequest would you expect
any mention of this in httpexceptions.rst or only
forward links from the pyramid.exceptions docs
into httpexceptions.rst?

It may take me a few days to get back to do more work
on this.

Karl kop@meme.com
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

@mmerickel

This comment has been minimized.

Copy link
Member

commented Oct 8, 2013

It's a framework-level exception, whereas pyramid.httpexceptions has been so far reserved for exception/responses that are directly mapping the http specs, so I don't think I'd expect to see a reference in there.

@mcdonc

This comment has been minimized.

Copy link
Member

commented Oct 9, 2013

I think the motivation for this is good. Like @mmerickel said, for bw compat purposes, it should subclass HTTPBadRequest, it should live in exceptions.py, and should just be called BadCSRFToken (without the HTTP-prefix).

@mmerickel

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

Closing this pull request, changes merged into #1169.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.