Ich kann mich nicht auf der Django-Administrationsseite anmelden. Wenn ich einen gültigen Benutzernamen und ein gültiges Kennwort eingebe, wird die Anmeldeseite nur noch ohne Fehlermeldungen angezeigt
Diese Frage ist in der Django FAQ , aber ich habe die Antworten dort durchgesehen und komme immer noch nicht an den anfänglichen Anmeldebildschirm vorbei.
Ich verwende Django 1.4 auf Ubuntu 12.04 mit Apache2 und Modwsgi.
Ich habe bestätigt, dass ich den Admin in der admin.py
-Datei registriert habe. Nachdem Sie INSTALLED_APPS
..__ hinzugefügt haben, stellen Sie sicher, dass syncdb verwendet wird. Wenn ich ein falsches Kennwort eingebe, erhalte ich DO einen Fehler, so dass mein Administrator Der Benutzer wird authentifiziert, geht aber nicht zur Admin-Seite weiter.
Ich habe sowohl SESSION_COOKIE_DOMAIN
als auch die IP des Rechners eingestellt. (Bestätigt, dass die Cookie-Domain als IP-Adresse des Computers in Chrom angezeigt wird.)
Außerdem wurde überprüft, ob sich der Benutzer über die Shell authentifiziert:
>>> from Django.contrib.auth import authenticate
>>> u = authenticate(username="user", password="pass")
>>> u.is_staff
True
>>> u.is_superuser
True
>>> u.is_active
True
Beim Anmeldeversuch mit IE8 und Chrome Canary wird der Anmeldebildschirm wieder angezeigt.
Gibt es noch etwas, was mir fehlt?
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-Version:
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
Die Administratorseite wird bei der Verwendung des Entwicklungsservers über runserver
fortgesetzt, sodass es sich um ein wsgi/Apache-Problem handelt. Ich habe es immer noch nicht herausgefunden.
L&OUML;SUNG
Das Problem war, dass die Einstellungsdatei SESSION_ENGINE
value auf 'Django.contrib.sessions.backends.cache'
ohne gesetzt und der CACHE_BACKEND
ordnungsgemäß konfiguriert wurde.
Ich habe SESSION_ENGINE in 'Django.contrib.sessions.backends.db'
geändert, wodurch das Problem behoben wurde.
Schritte zum Debuggen:
Django_session
-Tabelle ein Datensatz erstellt?WENN NICHT
Django_session
-Tabelle habenDjango_session
-Tabelle ein Datensatz erstellt?Lassen Sie mich wissen, wenn sich daraus ein nützlicher Debug ergibt.
Einstellungsdatei für Beispiele: 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
sollte True
sein
Wir hatten ein ähnliches Problem in unserer App und diese könnten helfen:
Verwenden Sie den Cleanup-Befehl, um ältere Sitzungen von Django_sessions zu löschen
Überprüfen Sie die Cookie-Größe in Firefox (Firebug) oder Chrome-Entwicklerwerkzeug. Da Messaging in admin standardmäßig aktiviert ist (Django.contrib.messages.middleware.MessageMiddleware), wird die Cookie-Größe bei mehrfachen Bearbeitungen und Löschungen manchmal größer als 4096 Byte. Ein schneller Test ist das Löschen des "Message" -Cookies und das Überprüfen, ob Sie sich danach anmelden können.
Und wir haben letztendlich auf nginx/uwsgi route umgestellt, wegen dieses und anderer Probleme mit dem Speicher von Apache. Ich habe dies seit nginx nicht wiederholt.
klingt wie ein Sitzungsproblem, weil Sie nach dem Beitrag umgeleitet werden und das System sofort vergessen hat, dass Sie sich angemeldet haben.
versuche Folgendes:
Ich glaube nicht, dass das Administratorkennwort in der Datei settings.py gespeichert ist. Es wird erstellt, wenn Sie zum ersten Mal syncdb verwenden. Ich denke, Sie haben entweder das Erstellen des Superbenutzers übersprungen oder nur einen Tippfehler gemacht. __ Versuchen Sie, im Terminal Ihrer Projektwurzel zu laufen:
python Django-admin.py erstellt einen Superuser
So können Sie Ihr Admin-Login erneut eingeben. Auch hier gesehen https://docs.djangoproject.com/de/dev/ref/Django-admin/
Wenn Sie einige andere Artikel zu diesem Thema durchgehen, könnte es sich auf sys.path beziehen. Können Sie sys.path überprüfen und vergleichen, wenn Sie den Dev-Server und WSGI ausführen.
Für einige Details schauen Sie in this und that article . Aber ich würde zuerst den Pfad sys.path überprüfen, bevor ich auf die Details dieses Artikels eingehen möchte.
Stellen Sie sicher, dass Sie mindestens eine site
zur Arbeit haben.
>>> from Django.contrib.sites.models import Site
>>> Site.objects.count()
(0.048) SELECT COUNT(*) FROM `Django_site`; args=()
1
Wenn Sie hier 0 sehen, erstellen Sie eine.
Ich hatte dieses Problem. Das Problem ist, dass ich in der Produktion zwei Variablen auf True
gesetzt habe, die es mir erlaubten, mich über https mit der Site zu verbinden.
SESSION_COOKIE_SECURE
und CSRF_COOKIE_SECURE
sollten auf False
gesetzt sein, wenn Sie auf localhost http entwickeln. Durch das Ändern dieser beiden Variablen in False
konnte ich mich bei der lokalen Administration bei der Administrationssite anmelden.
Ich bin nicht ganz sicher, aber das Problem könnte in Ihrer URL-Konfiguration liegen, konkret in diesen beiden Zeilen:
(r'^admin/', include(admin.site.urls)),
(r'^sites/', include("myproject.sites.urls")),
Vor einiger Zeit hatte ich Probleme beim Durchsuchen des Administrators meines Django-Projekts, da eine einzelne URL-Konfiguration einen Teil der Admin-URL überschrieb. Es scheint, dass Django es nicht mag, wenn Sie eine benutzerdefinierte URL-Konfiguration angeben, die Elemente enthält, die auch Bestandteil der Admin-URL sind. In Ihrem Fall haben Sie die App Django.contrib.sites
in Ihrem settings.py
aktiviert. Sie können auf das Admin-Panel dieser App zugreifen, indem Sie http://127.0.0.1:8000/admin/sites/
aufrufen. Möglicherweise überschreibt Ihre URL-Konfiguration mit r'^sites/'
einen Teil der Administrator-URL. Versuchen Sie, diese spezifische URL-Konfiguration umzubenennen, oder deaktivieren Sie Django.contrib.sites
in INSTALLED_APPS
zu Testzwecken.
Bitte beachten Sie, dass dies nur eine Annahme ist. Ich weiß nur, dass Djangos Admin-Panel ein wenig wählerisch ist, wenn es um URL-Konfigurationen geht, die ähnliche Namen wie ihre eigenen URLs verwenden. Ich kann es momentan nicht selbst testen. Aber vielleicht hilft dir das ein bisschen.
Haftungsausschluss: Ich kann noch keine Kommentare hinzufügen, daher muss ich hier eine Klarstellung einholen und gleichzeitig eine Lösung vorschlagen. Das tut mir leid.
Wird der Benutzer sofort nach der Anmeldung abgemeldet? etwas wie diese Ausgabe
Sie können es auf viele Arten überprüfen, ich schlage vor, das Abmeldesignal mit einem Haken zu versehen (Sie können es in Ihre models.py einfügen):
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)
versuchen Sie dann, sich anzumelden und zu überprüfen, ob die Meldung in Ihrer Konsole angezeigt wird. Wenn es angezeigt wird, müssen Sie nach der Anmeldung prüfen, ob Sie eine Umleitung oder eine benutzerdefinierte Vorlage für den Abruf haben. Ich hoffe, es hilft Ihnen, das Problem zu finden.
Nachdem ich mich nicht einloggen konnte, habe ich im obigen Kommentar jemanden gesehen, der über das Entfernen von Nicht-Standard-Einstellungen gesprochen hat.
Das Hinzufügen zu meinen lokalen Einstellungen löste es für mich
SESSION_COOKIE_SECURE = Falsch
Stellen Sie sicher, dass Ihre Datenbankbenutzertabelle mit dem folgenden Eintrag wahr ist:
is_staff => True (if exit).
is_active => True .
is_superuser => True.
Ich hatte dasselbe Problem und es wurde gerade nach dem Neustart des Servers behoben:
systemctl restart nginx
Ich hatte ein verwandtes Problem, bei dem ich mich einloggen wollte und die Seite hängen blieb, bevor der Socket schließlich getötet wurde. Es stellte sich heraus, dass ich tatsächlich angemeldet war, aber einer der Login-Signalprozessoren einfror.
Celery konnte seine asynchronen Aufgaben nicht an RabbitMQ übergeben, da der RabbitMQ-Server nicht gestartet werden konnte.
Haben Sie versucht, den Benutzer zu erstellen mit:
python manage.py createsuperuser
Ich habe das gleiche Problem, wenn ich die Datenbank auf einer Testmaschine erstelle und auf den Deployment Server migriere ...
Für mich konnte ich mich nicht auf der Admin-Seite in Firefox anmelden, sondern in Chrome ..__ Das Problem war, dass ich CSRF_COOKIE_PATH in meinen settings.py ..__ gesetzt hatte. Es funktioniert auf Django 1.8 nicht richtig.
Sie können sicherstellen, dass der erstellte Benutzer als Is_staff = True markiert wurde. Manchmal vergesse ich, dies zu kennzeichnen, damit sich Benutzer bei Django-Admin anmelden können