Что может вызвать ошибку Django, когда debug=False, которой нет, когда debug=True

Используя сервер разработки, он работает с debug=True или False.

В продакшене все работает, если отладка = True, но если отладка = False, я получаю ошибку 500, а журналы apache заканчиваются ошибкой импорта: «ImportError: не удается импортировать имя проекта».

Ничто в импорте не делает ничего зависящего от отладки - единственный код, который делает, - должен ли сервер разработки обслуживать статические файлы или нет (в производстве apache должен обрабатывать это - и это тестируется отдельно и работает нормально).


python django debugging apache importerror
person willcritchlow    schedule 11.02.2011    source источник
comment
вы используете 2 файла настроек или действительно меняете содержимое settings.py во время развертывания?   -  person orokusaki    schedule 11.02.2011
comment
У меня есть local_settings для dev, который переопределяет настройку отладки, но я вручную изменяю содержимое settings.py в производстве, чтобы убедиться, что это ошибка (это только внутренний инструмент, поэтому я могу делать такие вещи!) .   -  person willcritchlow    schedule 11.02.2011
comment
Моя работала, когда я делал python manage.py collectstatic перед тем, как делать runserver   -  person Aseem    schedule 02.04.2019

Ответы (4)


arrow_upward
7
arrow_downward

Это происходит, если у вас есть циклический импорт в одном из ваших файлов. Проверьте и посмотрите, импортируете ли вы что-то из Project, а затем импортируете что-то в Project из исходного файла, который изначально импортировал Project.

Недавно я столкнулся с этой же проблемой, и перестановка некоторых моих импортов помогла решить проблему.

person Ben Belchak    schedule 11.02.2011
comment
Да, ошибка, похоже, была связана с циклическим импортом, но я не понимаю, почему это будет работать с debug=True? Наверняка вы хотите, чтобы единственная разница между debug=True и False заключалась в отладочной информации, а не в том, работает она или нет? - person willcritchlow; 12.02.2011
comment
@willcritchlow - Да, меня беспокоит то же самое, но я еще не нашел ответа на последний вопрос. Может быть ошибка, когда в режиме DEBUG=True он молча обрабатывает исключение? - person Ben Belchak; 13.02.2011
comment
В дополнение к циклическим ссылкам, начиная с Django 1.6.2, если вы попытаетесь сослаться на переменную импортированного модуля, и если эта переменная не существует, DEBUG=True не приведет к сбою, но DEBUG=False произойдет. Например, попробуйте это с import exampleapp.settings, а затем с settings.variable_that_doesnt_exist - person ecoe; 10.09.2014

arrow_upward
76
arrow_downward

Просто скажу, что сегодня я столкнулся с подобной ошибкой, потому что Django 1.5 требует параметр ALLOWED_HOSTS в настройках. Вам просто нужно разместить эту строку, чтобы она работала;)

...
ALLOWED_HOSTS = '*'
...

Однако имейте в виду, что вам необходимо правильно установить этот параметр в соответствии с вашими фактическими хостами (https://docs.djangoproject.com/en/dev/ref/settings)./#allowed-hosts)!

Значения в этом списке могут быть полными именами (например, «www.example.com»), и в этом случае они будут точно сопоставлены с заголовком узла запроса (без учета регистра, без учета порта). Значение, начинающееся с точки, можно использовать в качестве подстановочного знака поддомена: «.example.com» будет соответствовать example.com, www.example.com и любому другому поддомену example.com. Значение '*' будет соответствовать чему угодно; в этом случае вы несете ответственность за обеспечение собственной проверки заголовка узла (возможно, в промежуточном программном обеспечении; в этом случае это промежуточное программное обеспечение должно быть указано первым в MIDDLEWARE_CLASSES).

Так что в основном вам лучше использовать этот тип конфигурации, когда вы находитесь в производстве:

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

спасибо gertvdijk за указание на это

person VAShhh    schedule 11.03.2013
comment
Ух ты!! Вопрос действительно старый (2 года назад), а ваш ответ недавний (6 часов назад), и вы избавили меня от головной боли. Спасибо! Вот мой плюс :) - person Caumons; 11.03.2013
comment
Вы тоже сэкономили мне время. Я бы увидел, что мне это нужно, если бы я создал свои проекты после февраля, поскольку этого не было в бета-версии или RC. Для всех, кто заинтересован, это может повлиять и на более старые версии: djangoproject.com/weblog /2013/февраль/19/безопасность - person John P. Neumann; 26.03.2013
comment
Это была моя точная проблема. В файле settings.py по умолчанию было ALLOWED_HOSTS = [], но изменение значения на ['*'] решило проблему. - person Justin Lang; 03.04.2013
comment
Это тоже сэкономило мое время, но кто-нибудь знает причину этого? - person nam; 22.04.2013
comment
Пожалуйста, не делайте этого. Это дыра в безопасности, которую вы открываете прямо здесь! Вместо этого укажите фактически разрешенные хосты HTTP. Этот параметр и поведение Django изменились не просто так. Прочтите это: Практические атаки HTTP-заголовка хоста - person gertvdijk; 02.05.2013
comment
@gertvdijk, я полагаю, вы имеете в виду ALLOWED_HOSTS = [*] — это дыра в безопасности, верно? (только для потомков, иначе похоже, что вы говорите, не используйте ALLOWED_HOSTS или что-то в этом роде) - person Josh Brown; 27.06.2014

arrow_upward
1
arrow_downward

Это также может произойти, если у вас нет шаблонов 500.html и 404.html. Просто 500 недостаточно, даже для URI, которые не будут давать 404!

person hed    schedule 17.08.2012

arrow_upward
1
arrow_downward

У меня тоже была эта проблема. Хотя это сохранялось даже при настройке Allowed_hosts и уже имея шаблоны 404 и 500.

Я также проверил круговой импорт, но это было не так.

Наконец, я заставил django создать файл журнала, https://stackoverflow.com/a/15100463/1577916

Я случайно оставил функцию «get_host», которая теперь существует в HttpRequest (изменена на HttpRequest.get_host()) с Django 1.5.

по какой-то причине это не вызывало ошибку с Debug True OR False.

person Michael Obranovich    schedule 08.05.2013