Не удалось войти на страницу администратора django с допустимым именем пользователя и паролем
Я не могу войти на страницу администратора django. Когда я ввожу действительное имя пользователя и пароль, он просто снова открывает страницу входа, без сообщений об ошибках
этот вопрос находится в Django FAQ, но я прошел ответы там и до сих пор не могу пройти мимо начального экрана входа в систему.
я использую django 1.4 на ubuntu 12.04 с apache2 и modwsgi.
Я подтвердил, что я Регистрация admin в , совершил обязательно syncdb после добавления INSTALLED_APPS
.
Когда я ввожу неправильный пароль я DO получить ошибку, поэтому мой пользователь администратора проходит проверку подлинности, просто не переходя на страницу администратора.
Я пробовал обе настройки SESSION_COOKIE_DOMAIN
на IP-адрес машины и нет. (Подтверждено, что домен cookie отображается как IP-адрес машины в chrome)
кроме того, проверено, что пользователь аутентифицируется через оболочку:
>>> from django.contrib.auth import authenticate
>>> u = authenticate(username="user", password="pass")
>>> u.is_staff
True
>>> u.is_superuser
True
>>> u.is_active
True
попытка входа с помощью IE8 и chrome canary, оба результаты того же возврата на экран входа в систему.
есть что-то еще я упускаю????
settings.py
...
MIDDLEWARE_CLASSES = (
'django.middleware.gzip.GZipMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)
AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend',)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.admin',
'django.contrib.staticfiles',
'django.contrib.gis',
'myapp.main',
)
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
SESSION_SAVE_EVERY_REQUEST = True
SESSION_COOKIE_AGE = 86400 # sec
SESSION_COOKIE_DOMAIN = None
SESSION_COOKIE_NAME = 'DSESSIONID'
SESSION_COOKIE_SECURE = False
urls.py
from django.conf.urls.defaults import * #@UnusedWildImport
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
(r'^bin/', include('myproject.main.urls')),
(r'^layer/r(?P<layer_id>d+)/$', "myproject.layer.views.get_result_layer"),
(r'^layer/b(?P<layer_id>d+)/$', "myproject.layer.views.get_baseline_layer"),
(r'^layer/c(?P<layer_id>d+)/$', "myproject.layer.views.get_candidate_layer"),
(r'^layers/$', "myproject.layer.views.get_layer_definitions"),
(r'^js/mapui.js$', "myproject.layer.views.view_mapjs"),
(r'^tilestache/config/$', "myproject.layer.views.get_tilestache_cfg"),
(r'^admin/', include(admin.site.urls)),
(r'^sites/', include("myproject.sites.urls")),
(r'^$', "myproject.layer.views.view_map"),
)
urlpatterns += staticfiles_urlpatterns()
Версия Apache:
Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured
Apache apache2 / сайты-доступно / по умолчанию:
<VirtualHost *:80>
ServerAdmin ironman@localhost
DocumentRoot /var/www/bin
LogLevel warn
WSGIDaemonProcess lbs processes=2 maximum-requests=500 threads=1
WSGIProcessGroup lbs
WSGIScriptAlias / /var/www/bin/apache/django.wsgi
Alias /static /var/www/lbs/static/
</VirtualHost>
<VirtualHost *:8080>
ServerAdmin ironman@localhost
DocumentRoot /var/www/bin
LogLevel warn
WSGIDaemonProcess tilestache processes=2 maximum-requests=500 threads=1
WSGIProcessGroup tilestache
WSGIScriptAlias / /var/www/bin/tileserver/tilestache.wsgi
</VirtualHost>
обновление
страница администратора продолжается при использовании сервера разработки через runserver
так кажется проблема с wsgi / apache. До сих пор не понял.
решение
проблема в том, что у меня был файл настроек SESSION_ENGINE
значение 'django.contrib.sessions.backends.cache'
без имеющего CACHE_BACKEND
правильно настроен.
Я изменил SESSION_ENGINE на 'django.contrib.sessions.backends.db'
который решил проблему.
16 ответов
шаги для отладки:
- убедитесь, что база данных синхронизирована
- дважды проверьте, что у вас есть django_session стол
- попробуйте для проверки подлинности
- вы видите запись, которая создается в
django_session
таблицы?
- вы видите запись, которая создается в
, ЕСЛИ НЕ
- удалить нестандартные параметры
- AUTHENTICATION_BACKENDS = ('Джанго.ВНО.автор.внутренний.ModelBackend',)
- SESSION_EXPIRE_AT_BROWSER_CLOSE = True
- SESSION_SAVE_EVERY_REQUEST = True
- SESSION_COOKIE_AGE = 86400 # sec
- 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
>>> 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
У нас была подобная проблема в нашем приложении, и это может помочь:
используйте команду очистки, чтобы очистить старые сеансы от django_sessions
проверьте размер файла 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/
звучит как проблема сеанса, потому что после сообщения Вы перенаправляетесь, и сразу система забыла, что вы вошли в систему.
попробуйте следующее:
- проверьте, что ваш бэкэнд сеанса работает.
- замените его с помощью бэкэнда кэша, если вы используете бэкэнд кэша БД, чтобы проверить, если промежуточное ПО транзакций возится.
- попробуйте 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.