Django - Неправильноконфигурированный: Модуль "django.contrib.auth.middleware"

Ответ 1

простое решение

просто удалите

'django.contrib.auth.middleware.SessionAuthenticationMiddleware',

от

MIDDLEWARE_CLASSES = (
...
...
)

в вашем проекте settings.py

тогда он должен работать!

Ответ 2

Я получал ту же ошибку. Но я забыл войти в свой VirtualEnv ПЕРЕД началом работы моего сервера. Поэтому убедитесь, что с терминала вы сначала активируете virtualenv: source env/bin/activate Затем запустите: python manage.py runserver

Ответ 3

Обратитесь к doc, Django в вашем активном virtualenv должен быть Django 1.7. А:

Это промежуточное программное обеспечение должно появиться после django.contrib.auth.middleware.AuthenticationMiddleware в MIDDLEWARE_CLASSES

Решает ли ваша проблема?

Ответ 4

бег

python3 manage.py runserver

вместо

python manage.py runserver

или

./manage.py runserver

Вы также можете отредактировать первую строку с заменой manage.py

\#!/usr/bin/env python

по

\#!/usr/bin/env python3

а затем запустите. /manage.py runningerver

(похоже, он работает, я не знаю, разрешен ли он проектом django)

Ответ 5

Я создал проект Django с Django 1.7 и попытался запустить его с Django 1.6.8. И у меня такая же ошибка. Я только что удалил

'django.contrib.auth.middleware.SessionAuthenticationMiddleware',

от

MIDDLEWARE_CLASSES =

в моем проекте settings.py. И это работает.

Ответ 6

Я столкнулся с проблемой, подобной этому сегодня (с использованием OS X Mavericks).

Прежде всего, у вас установлен django для вашей базовой ОС? Перед использованием Virtualenv я запускал Django непосредственно в ОС. Главное, что я заметил, я обычно набираю django-admin, а не django-admin.py. Это вызывало Django за пределами virtualenv, которое было версией 1.7.1.

Вне моего virtualenv я запустил pip удалить django, а затем вернулся в свой Virtualenv. Запуск django-admin --version без .py в конце возвращает "zsh: команда не найдена: django-admin" (она использовалась для возврата 1.7.1), однако при запуске django-admin.py --version возвращено 1.6. 5.

Убедитесь, что вы случайно не внесли наружную версию django прямо из вашей ОС, вам может потребоваться ввести django-admin.py

Ответ 7

Похоже, вы используете версию django до версии 1.7 (для версии 1.6.4), а SessionAuthenticationMiddleware не была введена до django 1.7. Следовательно, ошибка

Документацию можно найти здесь https://docs.djangoproject.com/en/1.7/ref/middleware/#django.contrib.auth.middleware.SessionAuthenticationMiddleware

В правом нижнем углу вы можете выбрать версию django. Выберите соответствующую версию и следуйте руководству, посвященному версии используемого django.

Ответ 8

Итак, я просто запустил новую установку своего виртуального сервера и запустил сервер, и теперь он работает как ожидалось. Проблема решена.

Ответ 9

Убедитесь, что вы используете $source bin/activate из корня вашего проекта. В противном случае просто продолжайте и уничтожьте свой проект и создайте новый. И если вы хотите стать разработчиком django, будьте готовы сделать много виртуальных.

При работе с отдельными ветвями, например, иногда бывает проще иметь два разных виртуальных файла и т.д., и когда вы перейдете на сервер, вы, вероятно, будете работать и с virtualenv. Так что это хорошая идея, чтобы хорошо справиться с ними и пройти через шаги.

Легко копировать файлы между каталогами с помощью команды $cp.

Ответ 10

Я использую версию Windows7/64, имел ту же ошибку. Согласился с user1776955, который указал на версию проблемы Django. поэтому самый простой способ - указать на Django-admin.py в оболочке. В моем случае это: python env\scripts\django-admin.py startproject my_django15_project

Ответ 11

Просто запустите его в Python 3:

python3 manage.py runserver

Если это сработает, рассмотрите также применение некоторых миграций приложений через: python3 manage.py migrate.

Ответ 12

Как мы видим в примечания к выпуску Django 1.8

django.contrib.auth.middleware.SessionAuthenticationMiddleware была добавлено в Django 1.7.

И вы используете Django-1.6.5 в своей виртуальной среде, следовательно, ошибку does not define.

Возможно, у вас установлена ​​более новая версия Django в вашей "нормальной" среде, и сервер работает правильно. Чтобы исправить эту версию Django обновления в вашей виртуальной среде (перед обновлением Django обязательно активируйте свою виртуальную среду!)

Теперь, чтобы добавить мои два цента к ответам, потому что все до сих пор было повторением от ZZY и user1776955

Если вы запустите pip install -U Django, вы, вероятно, столкнетесь со своей версией с чем-то выше 1.10, а затем примените следующее:

В Django 1.10 проверка сеанса будет включена независимо от независимо от того, включена ли SessionAuthenticationMiddleware (при которой точка SessionAuthenticationMiddleware не будет иметь никакого значения)

Следовательно, было бы безопасно удалить его, и если вы обновите его до версии 2.0, вы должны его удалить, потому что примечания к выпуску Django 2.0 сообщают, что

Класс SessionAuthenticationMiddleware удален. Он не предусматривал никаких функциональности, поскольку аутентификация сеанса безоговорочно включена в Django 1.10.

Также немного не связано, но актуально, когда обновление этой версии заключается в том, что

Поддержка промежуточного программного обеспечения старого стиля с использованием настроек. MIDDLEWARE_CLASSES удаляется

Насколько мне известно, достаточно изменить MIDDLEWARE_CLASSES только на MIDDLEWARE и удалить 'django.contrib.auth.middleware.SessionAuthenticationMiddleware' из списка.