Не удалось войти на страницу администратора django с действительным именем пользователя и паролем

Ответ 1

Шаги для отладки:

• Убедитесь, что ваша база данных синхронизирована
  • Дважды проверьте, что у вас есть таблица django_session.
• Попробуйте выполнить аутентификацию
  • Вы видите запись, созданную в таблице django_session?

ЕСЛИ НЕ

• удалить нестандартные настройки
  • AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend',)
  • SESSION_EXPIRE_AT_BROWSER_CLOSE = True
  • SESSION_SAVE_EVERY_REQUEST = True
  • SESSION_COOKIE_AGE = 86400 # сек
  • SESSION_COOKIE_DOMAIN = Нет
  • SESSION_COOKIE_NAME = 'DSESSIONID'
  • SESSION_COOKIE_SECURE = False
• Убедитесь, что ваша база данных синхронизирована
  • Дважды проверьте, что у вас есть таблица django_session
• Попробуйте выполнить аутентификацию
  • Вы видите запись, созданную в таблице django_session?

Сообщите мне, если это пригодится для любой полезной отладки.

Пример файла настроек: https://github.com/fyaconiello/Django-Blank-Bare-Bones-CMS/blob/master/dbbbcms/settings.py

Ответ 2

>>> from django.contrib.auth import authenticate
>>> u = authenticate(username="user", password="pass")
>>> u.is_staff True
>>> u.is_superuser True

Is there something else I'm missing????

u.is_active должен быть True

Ответ 3

Я не верю, что пароль администратора хранится в файле settings.py. Он был создан при первом syncdb. Я думаю, вы либо пропустили создание суперпользователя, либо просто сделали опечатку. Попробуйте запустить в терминале корни ваших проектов.:

python django-admin.py createuperuser

Это позволит вам повторно ввести свой логин администратора. Также см. Здесь https://docs.djangoproject.com/en/dev/ref/django-admin/

Ответ 4

У нас была аналогичная проблема в нашем приложении, и это могло бы помочь:

• Используйте команду очистки для удаления старых сеансов из django_sessions

• Проверьте размер файла cookie в firefox (firebug) или хром-инструментах для разработчиков. Поскольку обмен сообщениями включен по умолчанию в admin (django.contrib.messages.middleware.MessageMiddleware), размер файла cookie иногда превышает 4096 байт с несколькими изменениями и удалениями. Один быстрый тест - удалить cookie "message" и посмотреть, сможете ли вы войти в него после этого.

И мы фактически перешли на маршрут nginx/uwsgi из-за этого и других проблем, связанных с памятью с apache. Не видели, как это повторялось в nginx с тех пор.

Ответ 5

звучит как проблема сеанса, потому что после сообщения вы перенаправляетесь и сразу же система забыла, что вы вошли в систему.

попробуйте следующее:

• проверьте, работает ли ваш сеанс.
• обменивайте его с помощью кэширования, если вы используете бэкэйн кэша db, чтобы проверить, запущено ли промежуточное программное обеспечение транзакции.
• попробуйте db backend и проверьте, есть ли сеансы, хранящиеся в таблице db.

Ответ 6

Я не совсем уверен, но проблема может быть связана с вашей конфигурацией URL, конкретно в этих двух строках:

(r'^admin/', include(admin.site.urls)),  
(r'^sites/', include("myproject.sites.urls")),

До сих пор у меня были проблемы с просмотром admin моего проекта Django, потому что одна конфигурация URL-адреса переписала часть URL-адреса администратора. Похоже, что Django не нравится, когда вы указываете настраиваемую конфигурацию URL, которая содержит элементы, которые также являются частью URL-адреса администратора. В вашем случае приложение django.contrib.sites включено в вашем settings.py. Вы можете получить доступ к панели администратора этого приложения, перейдя в http://127.0.0.1:8000/admin/sites/. Возможно, ваша конфигурация URL с r'^sites/' в ней переопределяет часть URL-адреса администратора. Попробуйте переименовать эту конкретную конфигурацию URL или отключите django.contrib.sites в INSTALLED_APPS для целей тестирования.

Обратите внимание, что это всего лишь предположение. Все, что я знаю, это то, что панель администрирования Django немного придирчива к настройкам URL-адресов, используя похожие имена, такие как собственные URL-адреса. Я не могу проверить это сам в данный момент. Но, возможно, это поможет вам немного.

Ответ 7

Проверяя некоторые другие статьи по этой теме, это может быть связано с sys.path. Можете ли вы проверить и сравнить sys.path при запуске сервера dev и при запуске WSGI.

Для некоторых деталей посмотрите this и статья. Но сначала я проверил sys.path, прежде чем переходить к деталям этой статьи.

Ответ 8

Попробуйте, создав пользователя с помощью

python manage.py createsuperuser

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

Ответ 9

Убедитесь, что у вас есть хотя бы один site для работы.

>>> from django.contrib.sites.models import Site
>>> Site.objects.count()
(0.048) SELECT COUNT(*) FROM `django_site`; args=()
1

Если вы видите 0 здесь - создайте его.

Ответ 10

У меня была эта проблема. Проблема заключается в том, что в производственной среде я установил для двух переменных значение True что позволило мне подключаться к сайту по протоколу https.

SESSION_COOKIE_SECURE и CSRF_COOKIE_SECURE должны быть установлены в False если вы разрабатываете на локальном http. Изменение этих двух переменных на False позволило мне войти на сайт администратора при локальной разработке.

Ответ 11

Убедитесь, что в таблице пользователей вашей базы данных есть следующая запись:

is_staff  => True  (if exit).
is_active  => True .
is_superuser => True.

Ответ 12

Отказ от ответственности: я еще не могу добавлять комментарии, поэтому я должен просить разъяснения здесь, предлагая решение в одно и то же время. Извините за это.

Пользователь вышел из системы сразу после входа в систему? что-то вроде этой проблемы

Вы можете проверить его разными способами, я предлагаю добавить крюк к сигналу выхода (вы можете поместить его в свои models.py):

from django.contrib.auth.signals import user_logged_out

def alertme(sender, user, request, **kwargs):
    print ("USER LOGGED OUT!") #or more sophisticate logging

user_logged_out.connect(alertme)

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

Ответ 13

У меня была такая же проблема, и она была просто решена после перезапуска сервера:

systemctl restart nginx

Ответ 14

Вы можете гарантировать, что созданный пользователь был помечен как Is_staff = True, иногда забываю указать это, чтобы пользователи могли войти в django admin

Ответ 15

У меня была связанная проблема, когда я пытался войти в систему, и страница зависала до того, как сокет в конце концов был бы убит. Оказалось, что я действительно входил в систему, но один из процессоров сигналов входа в систему зависал.

Celery не смог передать свои асинхронные задачи RabbitMQ, потому что сервер RabbitMQ не смог запуститься.

Ответ 16

Для меня, я не мог войти на страницу администратора в Firefox, но мог войти в Chrome. Проблема была в том, что у меня в файле settings.py был установлен CSRF_COOKIE_PATH. Никогда не используйте это. На django 1.8 он не работает должным образом.

Ответ 17

После того, как я не смог войти в систему, я увидел в комментарии выше, что кто-то упоминал об удалении нестандартных настроек.

Добавление этого в мои локальные настройки решило это для меня

SESSION_COOKIE_SECURE = False