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

Question

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.

Answer 1

¿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 ...

Answer 2

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.

Answer 3

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/

Answer 4

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.

Answer 5

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.

Answer 6

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 ?

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
• Intenta autenticar
  • ¿Ves un registro que se está creando en la tabla django_session ?

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

Answer 7

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

Answer 8

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.

Answer 9

Tuve el mismo problema y fue resuelto después de reiniciar el servidor:

systemctl restart nginx

Answer 10

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.

Answer 11

Tuvimos un problema similar en nuestra aplicación y esto podría ayudar:

1. Utilice el comando de limpieza para borrar sesiones anteriores de django_sessions

2. 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.

Answer 12

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.

Answer 13

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.

Answer 14

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:

1. verifica que tu sesión backend esté funcionando.
2. 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.
3. intente db back-end y verifique si hay sesiones almacenadas en la tabla db

Answer 15

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