Impossible de se connecter à l’administrateur de Django en utilisant le nom d’utilisateur et le mot de passe corrects

J’ai déployé une application Django sur DigitalOcean en utilisant ngnix , gunicorn et une firebase database Postgresql . Tout fonctionne très bien et quand je lance python manage.py syncdb et que je suis capable de créer un utilisateur qui remplit bien ma firebase database.

Le problème est que lorsque j’essaie de me connecter à l’interface d’administration de Django, je suis invité à utiliser un nom d’utilisateur et / ou un mot de passe erroné. Je suis sûr que les identifiants sont corrects car j’ai essayé de configurer la firebase database plusieurs fois.

Des idées pour lesquelles Django pense que je saisis les mauvaises informations utilisateur?

Merci!

SETTINGS.py ressemble à

 # Build paths inside the project like this: os.path.join(BASE_DIR, ...) import os BASE_DIR = os.path.dirname(os.path.dirname(__file__)) # Quick-start development settings - unsuitable for production # See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/ # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = 'XXXXXXXXXXXXXXX' # SECURITY WARNING: don't run with debug turned on in production! DEBUG = True TEMPLATE_DEBUG = True ALLOWED_HOSTS = [] # Application definition INSTALLED_APPS = ( 'django.consortingb.auth', 'django.consortingb.contenttypes', 'django.consortingb.sessions', 'django.consortingb.sites', 'django.consortingb.messages', 'django.consortingb.staticfiles', 'django.consortingb.admin', ) MIDDLEWARE_CLASSES = ( 'django.consortingb.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.consortingb.auth.middleware.AuthenticationMiddleware', 'django.consortingb.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ) ROOT_URLCONF = 'qvido.urls' WSGI_APPLICATION = 'qvido.wsgi.application' # Database # https://docs.djangoproject.com/en/1.6/ref/settings/#databases DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'mydbname', 'USER': 'user', 'PASSWORD': 'pass!', 'HOST': 'localhost', 'ROOT': '', } } # Internationalization # https://docs.djangoproject.com/en/1.6/topics/i18n/ LANGUAGE_CODE = 'en-us' TIME_ZONE = 'UTC' USE_I18N = True USE_L10N = True USE_TZ = True # Static files (CSS, JavaScript, Images) # https://docs.djangoproject.com/en/1.6/howto/static-files/ STATIC_ROOT = '/webapps/django-env/static/' STATIC_URL = '/static/' 

WSGI.py ressemble à

 import os os.environ.setdefault("DJANGO_SETTINGS_MODULE", "qvido.settings") from django.core.wsgi import get_wsgi_application application = get_wsgi_application() 

MODIFIER

Ok, j’ai aussi essayé de faire python manage.py dbshell et le select * from auth_user; Je vois l’utilisateur que j’ai créé mais je ne peux toujours pas me connecter avec lui. Si étrange.

Je m’excuse pour la réponse tardive, mais je crois que cela peut être utile à quelqu’un.

J’avais le même problème. Après avoir lu tous les commentaires de la question initiale, j’ai pu comprendre ce qui s’était passé.

Au cours du développement, j’avais changé de firebase database d’un ancien fichier de test à un nouveau qui incluait toutes les tables requirejses au lieu de simplement modifier la firebase database existante. Je n’avais modifié que le fichier settings.py pour mettre à jour l’emplacement de la nouvelle firebase database et wsgi.py n’ai pas touché le fichier wsgi.py Après avoir migré vers la nouvelle firebase database et supprimé l’ancien fichier du projet, mon utilisateur admin n’existait pas dans la nouvelle firebase database.

Sur la base des commentaires de @Torsten Engelbrecht et de l’OP, il suffisait de lancer la commande suggérée par @Alen thomas pour la rendre à nouveau fonctionnelle:

 python manage.py createsuperuser 

À ce stade, j’ai pu configurer le même compte administrateur que celui que j’avais utilisé auparavant, car il n’existait plus. Maintenant tout fonctionne bien. Cela peut sembler un peu idiot, mais il vaut mieux vérifier la

Donc, j’ai trouvé la réponse à pourquoi cela se produisait et en effet, @scriptmonster était correct.

Lorsque j’ai installé Django, Gunicorn etc. dans mon virtual-env, j’ai utilisé sudo pip install qui les a installés en dehors de mon virtaul-env.

J’ai couru sudo chown -R myuser:myuser /webapps/myenv et a ensuite lancé pip install django et pip install gunicorn nouveau pip install gunicorn et tout fonctionnait très bien.