it-swarm-eu.dev

Nelze se přihlásit na stránku Django admin s platným uživatelským jménem a heslem

Nemohu se přihlásit na stránku Django admin. Když zadám platné uživatelské jméno a heslo, znovu se zobrazí přihlašovací stránka bez chybových zpráv

Tato otázka je v Django FAQ , ale tam jsem přešla odpovědi a stále nemůžu projít úvodní přihlašovací obrazovkou.

Používám Django 1.4 na ubuntu 12.04 s Apache2 a modwsgi.

Potvrdil jsem, že registruji administrátora v souboru admin.py. Po přidání INSTALLED_APPS. Se ujistěte, že je synchronizován. Když zadám nesprávné heslo I DO dostaneme chybu, takže můj administrátor je ověřován, neuskutečňuje stránku administrátora.

Zkoušel jsem nastavení SESSION_COOKIE_DOMAIN na IP adresu stroje a hodnotu None. (Potvrzeno, že doména souborů cookie se zobrazuje jako adresa IP zařízení v chromu)

Také zkontrolujte, zda se uživatel ověřuje prostřednictvím prostředí 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

Pokus o přihlášení pomocí IE8 a chrome canary, oba výsledky mají stejný návrat na přihlašovací obrazovku.

Je tu něco jiného, ​​co mi chybí ????

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

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

AKTUALIZACE

Stránka administrátora postupuje při použití vývojového serveru přes runserver, takže to vypadá jako problém wsgi/Apache. Ještě na to přišel.

ŘE&SCARON;EN&IACUTE;

Problém byl v tom, že jsem měl soubor nastavení SESSION_ENGINE nastaven na hodnotu 'Django.contrib.sessions.backends.cache'without s správně nakonfigurovaným CACHE_BACKEND

Změnil jsem SESSION_ENGINE na 'Django.contrib.sessions.backends.db', který problém vyřešil.

38
monkut

Kroky ladění:

  • Ujistěte se, že je databáze synchronizována
    • Zkontrolujte, zda máte tabulku Django_session
  • Pokuste se ověřit
    • Vidíte v tabulce Django_session vytvořený záznam?

POKUD NE

  • odstranit nestandardní nastavení
    • AUTHENTICATION_BACKENDS = ('Django.contrib.auth.backends.ModelBackend',)
    • SESSION_EXPIRE_AT_BROWSER_CLOSE = True
    • SESSION_SAVE_EVERY_REQUEST = True
    • SESSION_COOKIE_AGE = 86400 # sec
    • SESSION_COOKIE_DOMAIN = Žádný
    • SESSION_COOKIE_NAME = 'DSESSIONID'
    • SESSION_COOKIE_SECURE = False
  • Ujistěte se, že je databáze synchronizována
    • Zkontrolujte, zda máte tabulku Django_session
  • Pokuste se ověřit
    • Vidíte v tabulce Django_session vytvořený záznam?

Dejte mi vědět, pokud se objeví nějaké užitečné ladění.

Soubor vzorových nastavení: https://github.com/fyaconiello/Django-Blank-Bare-Bones-CMS/blob/master/dbbbcms/settings.py

47
>>> 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 by mělo být True

9
Burhan Khalid

V naší aplikaci jsme měli podobný problém.

  1. Použijte příkaz cleanup pro vymazání starších relací z Django_sessions

  2. Zkontrolujte velikost souboru cookie v firefox (firebug) nebo chrome nástroje pro vývojáře. Vzhledem k tomu, že zasílání zpráv je ve výchozím nastavení povoleno v aplikaci admin (Django.contrib.messages.middleware.MessageMiddleware), může být velikost souboru cookie někdy větší než 4096 bajtů s více úpravami a vymazáním. Jedním z rychlých testů je smazat cookie „message“ a zjistit, zda se po něm můžete přihlásit.

A my jsme vlastně skončili přechod na nginx/uwsgi trasu, protože toto a další problémy související s pamětí s Apache. Od té doby se to nezdálo opakovat v nginxu.

3
Raj J

zní to jako problém s relací, protože poté, co jste obdrželi přesměrování a okamžitě zapomenete, že jste se přihlásili.

zkuste následující:

  1. zkontrolujte, zda funguje backend vaší relace.
  2. vyměňte ji s vyrovnávací pamětí mezipaměti, pokud používáte backend db mezipaměti, abyste zkontrolovali, zda se transakce middleware nepořádá.
  3. zkuste db backend a zkontrolujte, zda jsou v db tabulce uloženy relace
2
frog32

Nevěřím, že heslo správce je uloženo v souboru settings.py. Je vytvořen při první synchronizaci. Myslím, že jste buď přeskočili vytvoření superuživatele nebo jen udělali překlep. Pokuste se běžet v terminálu ve vašem projektu.

python Django-admin.py createuperuser

To vám umožní přepsat vaše admin přihlášení. Vidíte také zde https://docs.djangoproject.com/en/dev/ref/Django-admin/

2
Kei Nagase

Kontrola některých dalších článků na toto téma by se mohla týkat sys.path. Můžete zkontrolovat a porovnat sys.path při spuštění dev serveru a při spuštění WSGI.

Pro některé detaily, podívejte se toto a to článek . Nejdříve bych však zkontroloval sys.path, než přejdu do podrobností tohoto článku.

1
schacki

Zkontrolujte, zda máte alespoň jednu site k práci. 

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

Pokud vidíte 0 zde - vytvořte jeden.

1
Alexey Kachayev

Měl jsem tento problém. Problém je v tom, že ve výrobě jsem nastavil dvě proměnné na True, což mi umožnilo připojit se k webu pomocí https.

SESSION_COOKIE_SECURE a CSRF_COOKIE_SECURE by měly být nastaveny na False pokud vyvíjíte na localhost http. Změna těchto dvou proměnných na False mi umožnila přihlásit se na stránku admin při lokálním vývoji.

1
Marquistador

Nejsem si úplně jistý, ale problém může být s vaší konfigurací URL, konkrétně v těchto dvou řádcích:

(r'^admin/', include(admin.site.urls)),  
(r'^sites/', include("myproject.sites.urls")),

Před delší dobou jsem měl problémy s procházením administrátora mého projektu Django, protože jediná konfigurace URL přepsala část url administrátora. Zdá se, že Django nemá rád, když zadáte vlastní konfiguraci URL, která obsahuje prvky, které jsou také součástí adresy URL administrátora. Ve vašem případě máte ve Django.contrib.sites zapnutou aplikaci settings.py. Můžete přistupovat k panelu admin této aplikace tím, že půjdete do http://127.0.0.1:8000/admin/sites/. Může se stát, že vaše konfigurace URL s r'^sites/' v ní přepíše část url admin. Zkuste zkusit přejmenovat tuto specifickou konfiguraci URL nebo vypnout Django.contrib.sites v INSTALLED_APPS pro účely testování.

Vezměte prosím na vědomí, že se jedná pouze o předpoklad. Jediné, co vím, je to, že Django admin panel je trochu vybíravý o URL konfiguracích, které používají podobné názvy jako jeho vlastní URL. V tuto chvíli si to nemůžu vyzkoušet. Ale možná vám to trochu pomůže.

1
pemistahl

Zřeknutí se práv: Zatím nemohu přidávat komentáře, takže zde musím požádat o objasnění, které navrhuje řešení současně. Omlouvám se za to.

Je uživatel přihlášen okamžitě po přihlášení? něco jako tento problém

Můžete to zkontrolovat mnoha způsoby, doporučuji přidat háček k odhlášení signálu (můžete ho vložit do svých modelů .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)

zkuste se přihlásit a zkontrolujte, zda se zpráva zobrazuje ve vaší konzole. Pokud se objeví, pak musíte zkontrolovat, zda máte po přihlášení přesměrování nebo přizpůsobené odhlášení z šablony. Doufám, že vám pomůže najít problém.

0
furins

Ujistěte se, že je tabulka uživatelů databáze, která má následující položku, platná:

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

Měl jsem stejný problém a po restartování serveru byl vyřešen:

systemctl restart nginx
0
lapin

Měl jsem související problém, kde bych se pokusil přihlásit a stránka by visela před tím, než by byla konečně zabita. Ukázalo se, že jsem byl skutečně přihlášen, ale jeden z procesorů pro přihlášení byl zmrazení.

Celery nemohl předat své asynchronní úkoly RabbitMQ, protože server RabbitMQ nebyl schopen začít.

0
kokociel

Pokusili jste se vytvořit uživatele pomocí:

python manage.py createsuperuser

Mám stejný problém, když jsem vytvořil db na testovacím stroji a přenesl ho na server pro nasazení ...

0
Lapin-Blanc

Pro mě jsem se nemohl přihlásit na stránku admin v firefoxu, ale mohl jsem se přihlásit v chromu. Na Django 1.8 to nefunguje správně.

0
max

Můžete se ujistit, že vytvořený uživatel byl označen jako Is_staff = True, občas zapomněl nahlásit toto, aby se uživatelé mohli přihlásit do aplikace Django admin

0
Timothy