J'ai une base de données postgres sur mon hôte local auquel je peux accéder sans mot de passe
$ psql -d mwt
psql (8.4.12)
Type "help" for help.
mwt=# SELECT * from vatid;
id | requester_vatid |...
-----+-----------------|...
1719 | IT00766780266 |...
Je veux accéder à cette base de données à partir de Django. Donc je mets dans DATABASES
DATABASES = {
'default': {
'ENGINE': 'Django.db.backends.postgresql_psycopg2',
'NAME': 'mwt',
'USER': 'shaoran',
'Host': 'localhost'
}
}
Comme je n'ai pas besoin d'un mot de passe pour accéder à ma base de données de test, je n'ai fourni aucune valeur PASSWORD
dans les paramètres.
$ ./manage.py Shell
>>> from polls.models import Vatid
>>> Vatid.objects.all()
connection_factory=connection_factory, async=async)
OperationalError: fe_sendauth: no password supplied
J'ai essayé d'utiliser PASSWORD: ''
mais je reçois le même message d'erreur. J'ai essayé d'utiliser PASSWORD: None
mais cela n'a pas aidé non plus.
J'ai parcouru la documentation de Django à ce sujet mais je ne trouve rien d'utile. Il est possible de configurer Django.db.backends.postgresql_psycopg2
pour accepter un mot de passe vide?
Vérifiez votre pg_hba.conf
pour autoriser la connexion de localhost
par l'utilisateur shaoran
, puis indiquez le mot de passe shaoran
dans les paramètres de Django ou faites confiance à l'utilisateur dans pg_hba.conf
Le fait que vous puissiez vous connecter via psql
est dû au fait que psql -d mwt
utilise certaines valeurs de connexion par défaut qui sont définies comme étant de confiance dans pg_hba.conf
. Par exemple, sur ma machine, l'hôte par défaut est local socket
au lieu de localhost
Étonnamment, la réponse est de ne pas spécifier un hôte du tout. Si tu fais ça,
DATABASES = {
'default': {
'ENGINE': 'Django.db.backends.postgresql_psycopg2',
'NAME': 'mwt',
}
}
Ensuite, psycopg2 se connectera à l’aide d’un socket Unix de la même manière que psql
. Lorsque vous spécifiez Host
, psycopg2 se connecte avec TCP/IP, ce qui nécessite un mot de passe.
Pour éviter d'utiliser un mot de passe dans Django settings.py
, remplacez md5
par trust
dans cette ligne de pg_hba.conf
:
Host all all 127.0.0.1/32 trust
Pour une compréhension détaillée des configurations de sécurité de postgres, lisez la présente doc.
Pour localiser ce fichier:
Sudo -u postgres psql -c 'SHOW hba_file;'
En tant que personne confrontée au même problème et ne trouvant une solution qu'après avoir combiné différentes parties des réponses présentes et des résultats des essais Google, j'ai décidé de préparer une réponse complète, espérons-le:
Première chose à noter:
Mettre 'Host'
ou l'omettre dans settings.py
est une option viable. Toutefois, que vous ajoutiez ou non 'Host'
affecte la configuration de la configuration de postgresql.
Omettre 'Host'
comme dans la réponse de joerick conduit à psycopg2 essayant de se connecter par socket de domaine Unix. D'autre part, si votre configuration contient la clé 'Host'
, psycopg2 tentera de se connecter via IPv4/6 localhost
. Cela fait une grande différence car la configuration de l'authentification postgresql (/etc/postgresql/x.x/main/pg_hba.conf
) est spécifique à l'une ou l'autre de ces façons de se connecter.
Message à la maison:
Assurez-vous de choisir le type de connexion que vous avez également configuré dans votre configuration d'authentification postgresql.
Deuxième chose à noter:
_ {La configuration de l'authentification postgresql (/etc/postgresql/x.x/main/pg_hba.conf
) se soucie de l'ordre des entrées.
Les docs sont en fait très clairs à ce sujet, (pourtant j'ai réussi à tomber dans le piège local all all peer
):
L'enregistrement premier avec un type de connexion, une adresse de client, une base de données demandée et un nom d'utilisateur, est utilisé pour effectuer l'authentification. Il n'y a pas de "sauvegarde directe" ou de "sauvegarde": si un enregistrement est choisi et que l'authentification échoue, les enregistrements suivants ne sont pas pris en compte. Si aucun enregistrement ne correspond, l'accès est refusé.
Message à la maison:
Assurez-vous que toute règle spécifique vient AVANT des règles plus larges.
Maintenant que nous savons tout cela, voici comment obtenir un accès sans mot de passe, une fois avec 'Host'
(donc sur localhost
) et une fois sans (ainsi sur une prise Unix).
localhost
Spécifiez 'Host': 'localhost'
dans la configuration de la base de données de votre settings.py
:
# ...
'Host': 'localhost',
# ...
'PASSWORD'
n'est pas nécessaire et peut être omis.
La règle que vous devez définir dans votre configuration d'authentification postgresql (/etc/postgresql/x.x/main/pg_hba.conf
) est pour TYPE Host
.
Attention à l'ordre des règles. Donc, si vous avez un utilisateur 'my_user' qui devrait pouvoir accéder à la base de données 'my_database' sans mot de passe, une configuration correcte ressemblera à ceci:
# RIGHT WAY...
Host my_database my_user 127.0.0.1/32 trust
Host my_database my_user ::1/128 trust
# ...
Host all all 127.0.0.1/32 peer
# ...
Inverser la commande entraînera une erreur no password supplied
.
Ne mettez pas la clé 'Host'
dans vos paramètres .'PASSWORD'
n'est pas nécessaire non plus.
Dans la configuration d'authentification postgresql, l'accès via les sockets de domaine Unix est géré avec des règles de TYPE local
.
Si 'my_user' doit être approuvé (aucun mot de passe requis) pour accéder à une base de données 'my_database', vous avez besoin d'une ligne comme celle-ci:
local my_database my_user trust
En ce qui concerne l'endroit où placer cette ligne, la règle ici est que vous devez la mettre avant toute règle plus large en termes de DATABASE
et USER
. Pour plus de sécurité, je recommande de le mettre au début de /etc/postgresql/x.x/main/pg_hba.conf
. Si votre fichier pg_hba.conf
ressemble à ceci:
# RIGHT WAY...
local my_database my_user trust
# ...
local all all peer
# ...
vous êtes bon pour aller sans mot de passe. Cependant, si cela ressemble à ceci:
# WRONG WAY! ...
local all all peer
# ...
local my_database my_user trust
# ...
vous devrez fournir un mot de passe.
Note finale:
N'oubliez pas de redémarrer le service postgresql après la modification de /etc/postgresql/x.x/pg_hba.conf
:
Sudo service postgresql restart
J'espère que cela a été utile. Bonne codage!
Je vis uniquement avec 'local all all all peer'. La chaîne de connexion doit être sans hôte, utilisateur et mot de passe: postgres: /// mydbname.
Sans le module environ, cela a l'air si:
DATABASES = {
'default': {'NAME': 'mydatabase', 'USER': '', 'PASSWORD': '', 'Host': '', 'PORT': '', 'ENGINE': 'Django.db.backends.postgresql_psycopg2'}
}
Avec le module environ:
import environ
env = environ.Env()
DATABASES = {
'default': env.db('DATABASE_URL', default='postgres:///mydatabase'),
}
où le fichier .env ne contient aucun paramètre DATABASE_URL.
J'utilise md5 uniquement pour l'utilisateur 'postgres', mais uniquement depuis psql/pgadmin3, pas depuis le code Django.
# /etc/postgresql/version/cluster/pg_hba.conf:
local all postgres md5
local all all peer