Невозможно войти на страницу администратора django с действительным именем пользователя и паролем
Я не могу войти на страницу администратора django. Когда я ввожу правильное имя пользователя и пароль, он просто снова открывает страницу входа без сообщений об ошибках
Этот вопрос есть в FAQ по django, но я просмотрел ответы там и до сих пор не могу пройти начальный экран входа в систему.
Я использую django 1.4 на Ubuntu 12.04 с apache2 и modwsgi.
Я подтвердил, что я регистрирую администратора в admin.py
файл, обязательно синхронизировать после добавления INSTALLED_APPS
, Когда я ввожу неправильный пароль, я действительно получаю сообщение об ошибке, поэтому мой пользователь с правами администратора проходит проверку подлинности, но не переходит на страницу администратора.
Я пробовал обе настройки 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 / sites-available / default:
<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'
который решил проблему.
26 ответов
Шаги для отладки:
- Убедитесь, что ваша база данных синхронизирована
- Дважды проверьте, что у вас есть таблица 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
>>> 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
У меня была эта проблема. Проблема в том, что в производстве я установил две переменные True
это позволило мне подключиться к сайту с помощью https.
SESSION_COOKIE_SECURE
а также CSRF_COOKIE_SECURE
должен быть установлен в False
если вы разрабатываете на localhost http. Изменение этих двух переменных на False
позволил мне войти в админ сайта при локальной разработке.
После того, как я не смог войти в систему, я увидел в комментарии выше, что кто-то упомянул об удалении нестандартных настроек.
Добавление этого в мои локальные настройки решило это для меня
SESSION_COOKIE_SECURE = Ложь
Я не верю, что пароль администратора хранится в файле settings.py. Он создается при первом запуске syncdb. Я думаю, что вы либо пропустили создание суперпользователя, либо просто сделали опечатку. Попробуйте запустить в терминале в ваших проектах root.
python django-admin.py создает пользователя
Это позволит вам повторно ввести ваш логин администратора. Также видно здесь https://docs.djangoproject.com/en/dev/ref/django-admin/
Вы пытались создать пользователя с помощью:
python manage.py createsuperuser
У меня та же проблема, когда я создаю базу данных на тестовой машине и переносу ее на сервер развертывания...
У нас была похожая проблема в нашем приложении, и они могут помочь:
Используйте команду cleanup для очистки старых сессий от django_sessions
Проверьте размер файла cookie в инструментах разработчика Firefox(Firebug) или Chrome. Поскольку обмен сообщениями по умолчанию включен в admin(django.contrib.messages.middleware.MessageMiddleware), размер файла cookie иногда становится больше 4096 байт с несколькими изменениями и удалениями. Одним из быстрых тестов является удаление cookie-файла "message" и проверка возможности входа после этого.
И мы фактически закончили тем, что переключились на маршрут nginx/uwsgi из-за этой и других проблем с памятью с apache. С тех пор я не видел этого в nginx.
Это не проблема ОП, но я публикую этот ответ в надежде, что кто-то, возможно, пошел по тому же пути, что и я, и в результате пришел к этому вопросу.
Я вернулся к старой кодовой базе через год, и мне было отказано в доступе к панели администратора, несмотря на прохождение всех обычных проверок (пользователь присутствует, в базе данных нет ничего неправильного, все режимы отладки включены и т. д.). К сожалению, я забыл, что страница входа администратора была не по обычному маршруту, а по альтернативному маршруту.
/admin
страница была поддельной страницей входа, которая всегда приводила к неудачному входу.
Эта установка была создана с помощью приложенияdjango-admin-honeypot
.
Звучит как проблема сеанса, потому что после публикации вы будете перенаправлены, и система сразу же забудет, что вы вошли в систему.
попробуйте следующее:
- проверьте, работает ли ваш бэкэнд сессии.
- поменяйте местами с кеш-сервером, если вы используете кеш-базу данных db, чтобы проверить, не мешает ли промежуточное ПО транзакций.
- попробуйте db backend и проверьте, есть ли сессии, хранящиеся в таблице db
Убедитесь, что в таблице пользователей вашей базы данных есть следующая запись:
is_staff => True (if exit).
is_active => True .
is_superuser => True.
Проверка некоторых других статей на эту тему может быть связана с sys.path. Можете ли вы проверить и сравнить sys.path при запуске сервера dev и при запуске WSGI.
Для некоторых деталей, посмотрите эту и ту статью. Но я бы сначала проверил sys.path, прежде чем углубляться в детали этой статьи.
Я не совсем уверен, но проблема может быть в вашей конфигурации URL, конкретно в этих двух строках:
(r'^admin/', include(admin.site.urls)),
(r'^sites/', include("myproject.sites.urls")),
Долгое время назад у меня были проблемы с просмотром администратора моего проекта Django, потому что одна конфигурация 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 здесь - создайте его.
Для меня ниже настройки работали на локальном хосте
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.ModelBackend',
]
SESSION_COOKIE_DOMAIN = None
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
Немного поздно для вечеринки, но для меня это было по-другому и на удивление проще: по какой-то причине моя учетная запись суперпользователя исчезла, поэтому, очевидно, решение заключалось в том, что мне пришлось создать ее снова.
Я на 99% уверен, что казнил
migrate
а также
makemigrations
несколько раз после создания моего суперпользователя, но поймите...
Однако мне потребовалось около часа, чтобы наконец понять это. Ни одна из обсуждаемых здесь переменных не существовала в моем файле settings.py — и до сих пор — (вероятно, потому, что прошло почти 10 лет, так что все могло значительно измениться), например
SESSION_ENGINE
,
SESSION_COOKIE_DOMAIN
,
CACHE_BACKEND
,
django_session
table...
Кроме того, в FAQ Django по этому вопросу упоминается проверка моей учетной записи
is_active
а также
is_staff
, но, к сожалению, даже не упоминая, как это сделать.
Для всех, кто столкнулся с этой проблемой после обновления Django, проблема может заключаться в том, что подпись функции в какой-то момент изменилась. Если подпись не соответствует ожидаемой, серверная часть просто игнорируется. Поэтому убедитесь, что ваш собственный сервер аутентификации
authenticate
метод выглядит так:
class EmailUsernameAuthenticationBackend(ModelBackend):
def authenticate(self, request, username=None, password=None, **kwargs):
# ...
И НЕ так (без
request
аргумент):
class EmailUsernameAuthenticationBackend(ModelBackend):
def authenticate(self, username=None, password=None, **kwargs):
В моем случае это всегда проблема с SESSION_COOKIE_DOMAIN: на локальной машине я установил это так:
SESSION_COOKIE_DOMAIN = 'localhost'
На удаленном, доменном, например:
SESSION_COOKIE_DOMAIN = 'yourdomainname.com'
У меня была проблема, связанная с тем, что я пытался войти в систему, и страница зависала до того, как сокет в конечном итоге был уничтожен. Оказалось, что я действительно входил в систему, но один из процессоров сигналов входа в систему зависал.
Celery не смог передать свои асинхронные задачи RabbitMQ, потому что сервер RabbitMQ не смог запуститься.
У меня была такая же проблема, и она была решена после перезапуска сервера:
systemctl restart nginx
Моя проблема решена, моя страница администратора не загружалась и не работала
pip uninstall django
pip install django==2.2
Для получения более подробной информации проверьте документацию Django
Вы можете убедиться, что созданный пользователь был помечен как Is_staff = True, иногда я забываю пометить это, чтобы разрешить пользователям входить в администратор django
Для меня я не мог войти на страницу администратора в Firefox, но мог войти в Chrome. Проблема была в том, что у меня в файле settings.py был установлен CSRF_COOKIE_PATH. Никогда не используйте это. На django 1.8 он не работает должным образом.
Что я сделал, так это вручную перешел к URL-адресу, который хотел посетить. Так нравится:http://wildlifeapi.herokuapp.com/admin/
возвращал ужасную ошибку приложения Heroku.
Итак, я посетил http://wildlifeapi.herokuapp.com/admin/api/animal/
и БИНГО! это сработало.
Самое смешное, что на моем телефоне он работает хорошо. Вероятно, это ошибка перенаправления django.
Отказ от ответственности: я не могу добавлять комментарии, поэтому я должен попросить разъяснений, предлагающих решение в то же время. Простите за это.
Выход пользователя из системы происходит сразу после входа в систему? что-то вроде этого вопроса
Вы можете проверить это разными способами, я предлагаю добавить ловушку к сигналу выхода из системы (вы можете поместить его в свой 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)
затем попробуйте войти в систему и проверить, появляется ли сообщение в вашей консоли. Если он появляется, то вам нужно проверить, есть ли у вас перенаправление или настроенный шаблон, вызывающий выход из системы после входа в систему. Надеюсь, это поможет вам найти проблему.
В моем случае я не смог войти в систему, потому что я использовал электронную почту вместо имени пользователя (которое в моем случае было «admin» ), чтобы попытаться войти. Поэтому убедитесь, что вы используете правильное имя пользователя и пароль для входа. авторизоваться
Используйте другую виртуальную среду. Это сработало для меня, когда я использовал среду conda.