On 06/10/2015 11:55 AM, Tim Graham wrote: > We added such a check in runserver [1].
Unfortunately, this doesn't help for the (likely) most common case of "local dev with runserver and DEBUG=True, deployment with another server and DEBUG=False". > For other servers it seems less > clear to me where that check would go -- in the WSGI handler? In > django.setup()? I was thinking django.setup() or directly in django.conf.settings. > (obviously, there is no need for ALLOWED_HOSTS if you > are using Django outside a webserver context, so the check could be > annoying if it's there). Yes, this is true. I guess we have to weigh the debugging issues caused by not having such a check against the (rare?) case of someone running Django in a non-request-serving capacity with a different settings file from the one they use to serve requests. (It's that latter clause that makes it seem a rare case to me - normally when you run e.g. Celery or some other type of worker process, you'd want to run it with exactly the same settings as your request-serving processes, in order to avoid other inconsistencies causing problems.) And the workaround for the annoying case would be simple - just go ahead and configure ALLOWED_HOSTS to something non-empty, even though you technically don't need it. Carl > [1] https://code.djangoproject.com/ticket/19875 > > On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote: > > On 06/10/2015 09:55 AM, Robert Roskam wrote: > > I realize this is a simple thing, but I'm sure this will save some > > people time. > > > > Since Allowed_Hosts is a required setting, when debug mode is off, it > > should raise an appropriate ImproperlyConfigured error. > > > > I'm sure there's some broader discussion surrounding which settings > > should have this and why, but I haven't been able to find it. > > This makes sense - a configuration with DEBUG=False and empty > ALLOWED_HOSTS can't possibly work, so why should we even allow it to > start up? Can anyone else recall a reason why we didn't do this? > > Carl > > -- > 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/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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/55788416.8070102%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
