CSRF_FAILURE_VIEW should not be used when DEBUG is False

1,111 views
Skip to first unread message

Žan Anderle

unread,
Aug 1, 2015, 11:28:57 AM8/1/15
to Django developers (Contributions to Django itself)
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 for it.


I could only find one comment related to this. And although it says 'Helpful 403 page if DEBUG is True' that's not really the case.

I wanted to check here if there is a reason for this behaviour before opening a ticket for it.

Have a great weekend :)
Žan

Tim Graham

unread,
Aug 7, 2015, 8:41:21 AM8/7/15
to Django developers (Contributions to Django itself)
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.

Žan Anderle

unread,
Aug 7, 2015, 8:47:23 AM8/7/15
to Django developers (Contributions to Django itself)
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.html template for other 4xx and 5xx statuses. Because the default CSRF failure template is not very user friendly.

Dne petek, 07. avgust 2015 14.41.21 UTC+2 je oseba Tim Graham napisala:

Tim Graham

unread,
Aug 7, 2015, 9:02:00 AM8/7/15
to Django developers (Contributions to Django itself)
I guess we might have to wait for Luke to reply to explain the reasoning for the original decision.

Luke Plant

unread,
Aug 10, 2015, 2:55:05 PM8/10/15
to django-d...@googlegroups.com
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 for this case. I haven't looked into it much, but probably it would be hard to pass the 'reason' to a generic template, without which developers will have a hard time debugging the problem.

Regards,

Luke
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/14115f91-7967-48b6-9843-586252fad624%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
OSBORN'S LAW
    Variables won't, constants aren't.

Luke Plant || http://lukeplant.me.uk/

Žan Anderle

unread,
Aug 17, 2015, 8:34:51 AM8/17/15
to Django developers (Contributions to Django itself)
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 napisala:
Reply all
Reply to author
Forward
0 new messages