-
Notifications
You must be signed in to change notification settings - Fork 40
Consider throwing a 400 instead of a 500 #28
Comments
Yeah, the logging aspect of this is probably pretty relevant. I think a big part of the reason why we historically throw (500) here is that it's expected to be a programming error on the part the app developer. This isn't an exception you'd ever want to handle in application code. At the same time, we don't want to redirect you into an auth flow since it's a misconfigured client. |
I'm fine changing this to a 400 - the client made an error and "forgot" to send the token. (Of course, philosophically, any client error could be conceived of as a server error because the programmer "forgot" to program something - support for a certain URL, verb, header, etc.) |
@rynowak BTW why the "auth flow" remark? A 400 won't take you to an auth flow (only 401/403 would do that). |
I know that I don't know anything about auth. |
Spoke to @pranavkm and @lodejard. Since there is a possibility for 500 to be thrown due to multiple reasons, the idea was to throw a custom |
So, I totes love custom exception types, but there's a difference between a failure of the antiforgery system, and an invalid token. Are you talking about the former or the latter? |
Spoke in person. We decided to throw a custom exception for no/invalid token cases and let the other cases just throw a 500. |
Not sure if it should be here or in MVC, but this seems like the right place.
I'm playing around with getting this to work for API calls. I notice that when I don't deliver an anti forgery token, the request results in a 500. Maybe this is just me, but shouldn't this be a 400? The server shouldn't fail (and log a 500) simply because I (or any other third party) forgets to add this token (read: bad request).
Exception I get is:
The text was updated successfully, but these errors were encountered: