Подтвердить что ты не робот

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

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

Этот вопрос находится в разделе django FAQ, но я перешел к ответам там и до сих пор не могу пройти мимо начального экрана входа.

Я использую django 1.4 на ubuntu 12.04 с apache2 и modwsgi.

Я подтвердил, что регистрирую администратор в файле admin.py, после добавления INSTALLED_APPS убедитесь, что syncdb. Когда я ввожу неправильный пароль, я получаю сообщение об ошибке, поэтому мой администратор аутентифицируется, просто не переходя на страницу администратора.

Я попытался установить SESSION_COOKIE_DOMAIN на IP-адрес устройства и None. (Подтверждено, что домен cookie отображается как IP-адрес устройства в хроме)

Также проверяется, что пользователь аутентифицируется через оболочку:

>>> 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 и хром-канарейки приводит к тому же возврату на экран входа в систему.

Есть ли что-то еще, что мне не хватает????

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/sites-available/default:

<VirtualHost *:80>
        ServerAdmin [email protected]
        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 [email protected]
        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>

UPDATE

Страница администрирования выполняется при использовании сервера разработки через runserver, поэтому кажется, что проблема wsgi/apache. Пока еще не понял.

Решение

Проблема заключалась в том, что у меня был установлен файл настроек SESSION_ENGINE, установленный на 'django.contrib.sessions.backends.cache', без правильной настройки CACHE_BACKEND.

Я изменил SESSION_ENGINE на 'django.contrib.sessions.backends.db', который разрешил проблему.

4b9b3361

Ответ 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