Fwd: Misleading 404 exception during unit tests.

[Benjamin Scherrey]

Raising the issue here. Ultimately, I think the 404 is ok but it needs to add details that will let the developer understand why a 404 is being returned. Of course this conflicts with much of the stated purpose of returning a 404 rather than the misconfigured exception but isn't the policy to NOT use this in production? So if we reveal a few extra details in a 404 exception that should be just fine, right?

thanx,

  -- Ben

---------- Forwarded message ----------
From: Tim Graham <timog...@gmail.com>
Date: Mon, Mar 23, 2015 at 10:41 PM
Subject: Re: Misleading 404 exception during unit tests.
To: django...@googlegroups.com

To have the decision revisited, you should raise it on django-developers.

On Monday, March 23, 2015 at 10:39:57 AM UTC-4, Ben Scherrey wrote:

Hey Tim,

   Appreciate the link. It looks like we're trying to have it go both ways here. If we don't want to allow it into production then make it explicit and break it - just as before. If we want to recommend that it not go into production but then let users actually do it, don't silently break it - just let it work and buyer beware. Requiring --insecure is fine but without it the explicit exception should be thrown I believe. In other words the original behaviour seems correct to me.

   I think silently absorbing exceptions is more dangerous than just outright breaking and exposing the root problem early. Many of the issues with the ORM have been due to a misapplication of this policy. I get the intent of the change but I'm not sure of the risk security-wise and have just experienced the impact of the misleading exception result personally.

  -- Ben

On Mon, Mar 23, 2015 at 9:19 PM, Tim Graham <timog...@gmail.com> wrote:

Please see https://github.com/django/django/commit/4c6ffcf7 for the rationale for the change. I am open to ideas, but I'm concerned that including details about the reason for the 404 might cause information leakage in production which wouldn't be desirable.

On Monday, March 23, 2015 at 10:06:25 AM UTC-4, Ben Scherrey wrote:

I see now that the behaviour of serve() was changed for 1.7 and it now returns a silent misleading 404 result rather than the old ImproperlyConfigured exception which would have provided a clue as to the actual root cause.

See: https://docs.djangoproject.com/en/1.7/ref/contrib/staticfiles/#django.contrib.staticfiles.views.serve

I don't understand the purpose of this change but it certainly sent me on a wild goose chase trying to understand the 404 response. Would be VERY useful if this 404 at least provided some information as to what it's really all about - preferably with the above link embedded in it.

Thanx to Rene Fleschenberg on irc for the doc link.

On Mon, Mar 23, 2015 at 8:42 PM, Benjamin Scherrey <prote...@gmail.com> wrote:

Can someone explain the test condition on line 31 of https://github.com/django/django/blob/master/django/contrib/staticfiles/views.py - Just spent a few hours trying to get my unit tests to pass and couldn't figure out what was going on until I found this weirdness.

I understand serve() isn't meant for production but, prior to having production ready it's nice to be able to unit test my code as it's being developed with serve() as a temporary measure. Right now I'm using serve() as a temporary hack to stand in for an external URI router that isn't present yet. Throwing a 404 without any helpful indication of the true cause of the exception simply confuses people and makes them wonder why the URI they're passing in is not being found when they can try it on the command line and see it work just fine. At minimum this exception should be more explicit.

--

Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!

--

Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6b30729f-5a8f-47e2-81f3-d73c44b697e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fcf4f6ca-284b-48db-b661-406e43fed57a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!