python - No se puede iniciar sesión en la página de administración de django con un nombre de usuario y contraseña válidos
login mod-wsgi (15)
¿Intentó creando el usuario con:
python manage.py createsuperuser
Tengo el mismo problema cuando creo el db en una máquina de prueba y lo migro al servidor de implementación ...
No puedo iniciar sesión en la página de administración de django. Cuando ingreso un nombre de usuario y contraseña válidos, solo aparece la página de inicio de sesión, sin mensajes de error
Esta pregunta está en las preguntas frecuentes de django , pero revisé las respuestas allí y todavía no puedo pasar la pantalla de inicio de sesión.
Estoy usando django 1.4 en ubuntu 12.04 con apache2 y modwsgi.
Confirmé que estoy registrando el administrador en el archivo admin.py
, me aseguré de sincronizar después de agregar INSTALLED_APPS
. Cuando ingreso la contraseña incorrecta, SI aparece un error, mi usuario administrador se autentica, simplemente no procede a la página de administración.
Intenté configurar SESSION_COOKIE_DOMAIN
en el IP de la máquina y Ninguno. (Confirmado que el dominio de la cookie muestra como IP de la máquina en cromo)
Además, verificó que el usuario se autentica a través del 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
Intento de inicio de sesión utilizando IE8 y Chrome Canary, ambos resultados en el mismo regreso a la pantalla de inicio de sesión.
¿Hay algo más que me falta ???
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()
Versión de 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>
ACTUALIZAR
La página de administración procede cuando se utiliza el servidor de desarrollo a través de runserver
por lo que parece un problema de wsgi / apache. Todavía no lo he descubierto todavía.
SOLUCIÓN
El problema era que tenía el valor ''django.contrib.sessions.backends.cache''
archivo de configuración establecido en ''django.contrib.sessions.backends.cache''
sin tener configurado correctamente CACHE_BACKEND
.
Cambié el SESSION_ENGINE a ''django.contrib.sessions.backends.db''
que resolvió el problema.
Descargo de responsabilidad: no puedo agregar comentarios todavía, así que tengo que pedir aclaraciones aquí proponiendo una solución al mismo tiempo. Lo siento por eso.
¿El usuario ha cerrado sesión inmediatamente después de iniciar sesión? algo así como este problema
Puede verificarlo de muchas maneras, le sugiero que agregue un enlace a la señal de cierre de sesión (puede ponerlo en su 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)
luego intente iniciar sesión y verifique si el mensaje aparece en su consola. Si aparece, entonces debe verificar si tiene un redireccionamiento o una plantilla personalizada para cerrar la sesión luego de iniciar sesión. Espero que te ayude a encontrar el problema.
No creo que la contraseña de administrador esté almacenada en el archivo settings.py. Se crea cuando se sincroniza por primera vez. Estoy pensando que o salteaste la creación del superusuario o simplemente cometiste un error tipográfico. Intenta ejecutar en la terminal en la raíz de tus proyectos .:
python django-admin.py creauperusuario
Eso te permitirá volver a escribir tu nombre de usuario de administrador. También visto aquí https://docs.djangoproject.com/en/dev/ref/django-admin/
No estoy exactamente seguro, pero el problema podría ser con su configuración de URL, concretamente en estas dos líneas:
(r''^admin/'', include(admin.site.urls)),
(r''^sites/'', include("myproject.sites.urls")),
Hace mucho tiempo, tuve problemas para explorar el administrador de mi proyecto Django porque una sola configuración de URL sobrescribía una parte de la URL del administrador. Parece que a Django no le gusta cuando especifica una configuración de URL personalizada que contiene elementos que también forman parte de la URL de administrador. En su caso, tiene la aplicación django.contrib.sites
habilitada en su settings.py
. Puede acceder al panel de administración de esta aplicación en http://127.0.0.1:8000/admin/sites/
. Puede ser que su configuración de URL con r''^sites/''
en ella anule una parte de la url de administración. Intente cambiar el nombre de esta configuración de URL específica o deshabilite django.contrib.sites
en INSTALLED_APPS
para fines de prueba.
Tenga en cuenta que esto es solo una suposición. Todo lo que sé es que el panel de administración de Django es un poco exigente con las configuraciones de URL que usan nombres similares, como sus propias URL. No puedo probarlo yo mismo en este momento. Pero tal vez esto te ayude un poco.
Para mí, no pude ingresar a la página de administración en Firefox, pero podía iniciar sesión en Chrome. El problema fue que tenía CSRF_COOKIE_PATH configurado en mi settings.py. Nunca uses eso. No funciona correctamente en django 1.8.
Pasos para depurar:
- Asegúrate de que tu base de datos esté sincronizada
- Verifica que tengas una tabla django_session
- Intenta autenticar
- ¿Ves un registro que se está creando en la tabla
django_session
?
- ¿Ves un registro que se está creando en la tabla
SI NO
- eliminar configuraciones no estándar
- AUTHENTICATION_BACKENDS = (''django.contrib.auth.backends.ModelBackend'',)
- SESSION_EXPIRE_AT_BROWSER_CLOSE = True
- SESSION_SAVE_EVERY_REQUEST = True
- SESSION_COOKIE_AGE = 86400 # seg
- SESSION_COOKIE_DOMAIN = Ninguno
- SESSION_COOKIE_NAME = ''DSESSIONID''
- SESSION_COOKIE_SECURE = False
- Asegúrate de que tu base de datos esté sincronizada
- Verifica que tengas una tabla
django_session
- Verifica que tengas una tabla
- Intenta autenticar
- ¿Ves un registro que se está creando en la tabla
django_session
?
- ¿Ves un registro que se está creando en la tabla
Avísame si aparece alguna depuración útil.
Archivo de configuración de muestra: https://github.com/fyaconiello/Django-Blank-Bare-Bones-CMS/blob/master/dbbbcms/settings.py
Puede asegurarse de que el usuario creado haya sido marcado como Is_staff = True, a veces me olvido de marcar esto para permitir que los usuarios inicien sesión en django admin
Tenía un problema relacionado en el que intentaba iniciar sesión y la página se bloqueaba antes de que finalmente se matara el zócalo. Resultó que de hecho estaba conectado, pero uno de los procesadores de señal de inicio de sesión se estaba congelando.
Apio no pudo pasar sus tareas asíncronas a RabbitMQ porque el servidor RabbitMQ no pudo iniciarse.
Tuve el mismo problema y fue resuelto después de reiniciar el servidor:
systemctl restart nginx
Tuve este problema El problema es que en producción establecí dos variables en True
que me permitieron conectarme al sitio usando https.
CSRF_COOKIE_SECURE
y CSRF_COOKIE_SECURE
deben establecerse en False
si está desarrollando en localhost http. Cambiar estas dos variables a False
me permitió iniciar sesión en el sitio de administración cuando se desarrollaba localmente.
Tuvimos un problema similar en nuestra aplicación y esto podría ayudar:
Utilice el comando de limpieza para borrar sesiones anteriores de django_sessions
Verifique el tamaño de la cookie en Firefox (Firebug) o en las herramientas de desarrollo de Chrome. Debido a que la mensajería está habilitada de forma predeterminada en admin (django.contrib.messages.middleware.MessageMiddleware), el tamaño de la cookie a veces supera los 4096 bytes con múltiples ediciones y borrados. Una prueba rápida es eliminar la cookie "mensaje" y ver si puede iniciar sesión después de eso.
Y en realidad terminamos cambiando a la ruta nginx / uwsgi debido a esto y otros problemas relacionados con la memoria con apache. No he visto esto repetido en nginx desde entonces.
Verificando otros artículos sobre este tema, podría estar relacionado con sys.path. Puede verificar y comparar sys.path cuando se ejecuta el servidor de desarrollo y cuando se ejecuta WSGI.
Para algunos detalles, eche un vistazo a this y ese article . Pero primero verificaría sys.path, antes de entrar en los detalles de este artículo.
Verifique que tenga al menos un site
para trabajar.
>>> from django.contrib.sites.models import Site
>>> Site.objects.count()
(0.048) SELECT COUNT(*) FROM `django_site`; args=()
1
Si ve 0 aquí, cree uno.
suena como un problema de sesión porque después de la publicación se te redirige e inmediatamente el sistema ha olvidado que has iniciado sesión.
intente lo siguiente:
- verifica que tu sesión backend esté funcionando.
- cámbielo por back-end de caché si usa back-end de caché de db para verificar si el middleware de transacción está dando vueltas.
- intente db back-end y verifique si hay sesiones almacenadas en la tabla db
>>> 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
debe ser True