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
On 07/08/15 14:02, Tim Graham wrote:
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 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:
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!
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.
https://code.djangoproject.com/ticket/9977
<https://code.djangoproject.com/ticket/9977>
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
--
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-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-developers@googlegroups.com
<mailto:django-developers@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
<https://groups.google.com/d/msgid/django-developers/14115f91-7967-48b6-9843-586252fad624%40googlegroups.com?utm_medium=email&utm_source=footer>.
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/
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/55C8F37B.9010209%40cantab.net.
For more options, visit https://groups.google.com/d/optout.
