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

>>> 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

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

1. используйте команду очистки, чтобы очистить старые сеансы от django_sessions

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

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

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

python django-admin.py createsuperuser

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

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

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

1. проверьте, что ваш бэкэнд сеанса работает.
2. замените его с помощью бэкэнда кэша, если вы используете бэкэнд кэша БД, чтобы проверить, если промежуточное ПО транзакций возится.
3. попробуйте DB backend и проверьте, есть ли сеансы, хранящиеся в таблице db

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

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

более давно у меня были проблемы с просмотром администратора моего проекта 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. В данный момент я не могу проверить это сам. Но, может быть, это немного помогает.

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

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

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

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

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

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

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

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

- пользователь регистрируется-сразу после входа-в? что-то вроде этот вопрос

вы можете проверить его многими способами, я предлагаю добавить крюк к сигналу выхода из системы (вы можете поместить его в свой 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)

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

вы пытались создать пользователя с помощью:

python manage.py createsuperuser

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

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

systemctl restart nginx

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

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

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

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

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

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