it-swarm.com.ru

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

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

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

Я использую Django 1.4 на Ubuntu 12.04 с Apache2 и modwsgi.

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

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

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

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

ОБНОВЛЕНИЕ

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

РЕШЕНИЕ

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

Я изменил SESSION_ENGINE на 'Django.contrib.sessions.backends.db', что решило проблему.

38
monkut

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

  • Убедитесь, что ваша база данных синхронизирована
    • Дважды проверьте, что у вас есть таблица 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

47
Francis Yaconiello
>>> 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

9
Burhan Khalid

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

  1. Используйте команду cleanup для очистки старых сессий от Django_sessions

  2. Проверьте размер файла cookie в инструментах разработчика Firefox (Firebug) или Chrome. Поскольку обмен сообщениями по умолчанию включен в admin (Django.contrib.messages.middleware.MessageMiddleware), размер файла cookie иногда становится больше 4096 байт с несколькими изменениями и удалениями. Одним из быстрых тестов является удаление cookie-файла «message» и проверка возможности входа после этого.

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

3
Raj J

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

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

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

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

python Django-admin.py создает пользователя

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

2
Kei Nagase

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

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

1
schacki

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

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

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

1
Alexey Kachayev

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

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

1
Marquistador

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

1
pemistahl

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

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

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

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

0
furins

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

is_staff  => True  (if exit).
is_active  => True .
is_superuser => True.
0
Dnyaneshwar Mahajan

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

systemctl restart nginx
0
lapin

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

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

0
kokociel

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

python manage.py createsuperuser

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

0
Lapin-Blanc

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

0
max

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

0
Timothy