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: > > 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 >>>> >>>> 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-develop...@googlegroups.com <javascript:>. > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > 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/b65c5444-8ea6-4c44-8bcb-21ff6ee4cb43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
