That makes sense. I wonder if there is a way to support both point of
views? Something like showing the 'default' 403 and logging the error to
make sure the developers know what's going on... Not sure, would be nice
though :)
Dne ponedeljek, 10. avgust 2015 20.55.05 UTC+2 je oseba Luke Plant na
When users see a CSRF failure, it is almost always because of mistake
made by the developer, and it is more useful under those circumstances
for the users to see a more specific error message that will help
developers rectify the problem. A generic 403 template is very unlikely
to be helpful fo
I guess we might have to wait for Luke to reply to explain the reasoning
for the original decision.
On Friday, August 7, 2015 at 8:47:23 AM UTC-4, Žan Anderle wrote:
>
> That's true. But it still seems a bit off, that all other 4xx will be
> handled diffrently with DEBUG=False. Shouldn't the def
That's true. But it still seems a bit off, that all other 4xx will be
handled diffrently with DEBUG=False. Shouldn't the default behavior for
csrf failure be the same? So while it's not a bug, I still don't get it why
I should update the view for CSRF failure, while I only need to create
4xx.ht
It doesn't seem to be a bug to me as there's nothing in the documentation
that says the view should only be used when DEBUG=True. The default
template also includes logic to vary the content based on DEBUG.
On Saturday, August 1, 2015 at 11:28:57 AM UTC-4, Žan Anderle wrote:
>
> Hey everyone!
>
Hey everyone!
I noticed today that CSRF_FAILURE_VIEW is used even when DEBUG=False. I'm
not sure why this is so and I think it would make much more sense to use
default 403 handling when DEBUG=False.
I checked the ticket where this was initially added, to see if there was a
particular reason f
