16

Using the development server, it works with debug=True or False.

In production, everything works if debug=True, but if debug=False, I get a 500 error and the apache logs end with an import error: "ImportError: cannot import name Project".

Nothing in the import does anything conditional on debug - the only code that does is whether the development server should serve static files or not (in production, apache should handle this - and this is tested separately and works fine).

willcritchlow
  • 721
  • 3
  • 7
  • 18
  • are you using 2 settings files, or are you actually changing the contents of `settings.py` during deployment? – orokusaki Feb 11 '11 at 15:20
  • I have a local_settings for dev that over-rides the setting of debug - but I am manually changing the contents of settings.py in production to verify that this is the bug (it's only an internal tool so I can do things like that!). – willcritchlow Feb 11 '11 at 15:39
  • Mine worked when I did `python manage.py collectstatic` before doing `runserver` – Aseem Apr 02 '19 at 04:59

4 Answers4

75

Just to say, I ran into a similar error today and it's because Django 1.5 requires the ALLOWED_HOSTS parameter in the settings. You simply need to place this row to make it work ;)

...
ALLOWED_HOSTS = '*'
...

However, be aware that you need to set this parameter properly according to your actual host(s) (https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts)!

Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).

So basically it's better for you to use this type of configuration once you're in production:

...
ALLOWED_HOSTS = [
    '.yourdomain.com',
]
...

thanks to gertvdijk for pointing this out

Community
  • 1
  • 1
VAShhh
  • 3,494
  • 2
  • 24
  • 37
  • 5
    Wow!! The question is really old (2 years ago) and your answer is recent (6 hours ago) and you saved me a headache. Thanks! Here is my upvote :) – Caumons Mar 11 '13 at 16:25
  • You have saved me some time as well. Would have seen that I needed that had I created my projects after February since this wasn't in the Beta or RC's. For anyone else interested it may affect older versions as well: https://www.djangoproject.com/weblog/2013/feb/19/security/ – John P Mar 26 '13 at 19:49
  • 1
    This was my exact problem. The default settings.py file had ALLOWED_HOSTS = [] but changing the value to ['*'] solved the problem. – Justin Lang Apr 03 '13 at 03:11
  • It saved my time too, but what somebody know the reason for that? – nam Apr 21 '13 at 20:11
  • 1
    Please **don't do this**. It's a security hole you're opening right there! Instead, specify the actual allowed HTTP hosts. This setting and behaviour of Django has changed for a reason. Read this: [Practical HTTP Host header attacks](http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html) – gertvdijk May 02 '13 at 08:25
  • @gertvdijk, i assume you're referring to the ALLOWED_HOSTS = [*] is a security hole, correct? (just for posterity, otherwise it looks like you're saying dont use ALLOWED_HOSTS or something) – Josh Brown Jun 27 '14 at 16:59
7

This happens if you have a circular import in one of your files. Check and see if you are importing something from Project and then importing something in Project from the original file that originally imported Project.

I ran into this same problem recently, and rearranging some of my imports helped fix the problem.

Ben Belchak
  • 549
  • 3
  • 6
  • 2
    Yes - the error did seem to be related to a circular import - but I'm confused about why it would work with debug=True? Surely you want the only difference between debug=True and False to be debug info - not *whether it works or not*? – willcritchlow Feb 12 '11 at 19:31
  • @willcritchlow - Yes, I have the same concern, but I have yet to find the answer to the latter question. There may be a bug where in DEBUG=True mode, it is silently handling the exception? – Ben Belchak Feb 13 '11 at 04:35
  • In addition to circular references, as of Django 1.6.2, if you try referencing a variable of an imported module, and if that variable does not exist, DEBUG=True will not crash but DEBUG=False will. For example, try this with `import exampleapp.settings` and then `settings.variable_that_doesnt_exist` – ecoe Sep 09 '14 at 22:55
1

This can also happen if you do not have both a 500.html and 404.html template present. Just the 500 isn't good enough, even for URIs that won't produce a 404!

hed
  • 31
  • 2
1

I had this problem as well. Although it persisted even when setting Allowed_hosts and already having 404 and 500 templates.

I also checked for circular imports, but that was not it.

I finally had django produce a log file, https://stackoverflow.com/a/15100463/1577916

I accidentally left in a "get_host" function which now exists under HttpRequest (changed to HttpRequest.get_host())with Django 1.5.

for some reason that was not raising an error with Debug True OR False.

Community
  • 1
  • 1
Michael Obranovich
  • 65
  • 6