Continuez à lire, les meilleures options viennent en dernier . Mais clarifions d'abord quelques points.
Silence uniquement la demande de mot de passe
Si votre problème est uniquement l'invite de mot de passe, vous pouvez la désactiver. Je cite le manuel ici :
-w
--no-password
N'émettez jamais d'invite de mot de passe. Si le serveur requiert une authentification par mot de passe et qu'un mot de passe n'est pas disponible par d'autres moyens tels qu'un
.pgpass
fichier, la tentative de connexion échouera. Cette option peut être utile dans les travaux par lots et les scripts où aucun utilisateur n'est présent pour entrer un mot de passe. (...)
Vous n'avez probablement pas besoin d'un mot de passe
Normalement, cela n'est pas nécessaire. Le superutilisateur de base de données par défaut postgres
correspond généralement à l'utilisateur système du même nom. Exécution de psql
de ce compte ne nécessite pas de mot de passe si la méthode d'authentification peer
ou ident
sont définis dans votre pg_hba.conf
dossier. Vous avez probablement une ligne comme celle-ci :
local all postgres peer
Et généralement aussi :
local all all peer
Cela signifie que chaque local l'utilisateur peut se connecter à tous base de données en tant qu'utilisateur de base de données du même nom sans mot de passe.
Cependant , il y a une idée fausse commune ici. Je cite à nouveau :
Cette méthode n'est prise en charge que sur les connexions locales .
Gras gras de la mienne.
Vous vous connectez à localhost
, qui n'est pas une "connexion locale" , même s'il contient le mot "local". Il s'agit d'une connexion TCP/IP vers 127.0.0.1. Wikipédia sur localhost :
Sur les systèmes informatiques modernes,
localhost
car un nom d'hôte se traduit par une adresse IPv4 dans le127.0.0.0/8
(loopback) net block, généralement127.0.0.1
, ou::1
en IPv6.
Solution simple pour les connexions locales
Omettre le paramètre -h
depuis le psql
invocation. Citant le manuel sur psql
une fois de plus :
Si vous omettez le nom d'hôte, psql se connectera via un socket de domaine Unix à un serveur sur l'hôte local, ou via TCP/IP à
localhost
sur les machines qui n'ont pas de sockets de domaine Unix.
Windows
... n'a pas de sockets de domaine Unix, pg_hba.conf
lignes commençant par local
ne sont pas applicables sous Windows. Sous Windows, vous vous connectez via localhost
par défaut, ce qui nous ramène au début.
Si vos exigences de sécurité sont laxistes, vous pouvez simplement faire confiance à toutes les connexions via localhost
:
host all all 127.0.0.1/32 trust
Je ne ferais cela que pour le débogage avec les connexions à distance désactivées. Pour plus de sécurité, vous pouvez utiliser l'authentification SSPI sous Windows. Ajoutez cette ligne à pg_hba.conf
pour les connexions "locales" :
host all all 127.0.0.1/32 sspi
Si vous avez réellement besoin d'un mot de passe
Vous pourriez définir une variable d'environnement , mais cela est déconseillé , en particulier pour Windows. Le manuel :
PGPASSWORD
se comporte de la même manière que le paramètre de connexion du mot de passe. L'utilisation de cette variable d'environnement n'est pas recommandée pour des raisons de sécurité, car certains systèmes d'exploitation permettent aux utilisateurs non root de voir les variables d'environnement de processus via ps ; pensez plutôt à utiliser le~/.pgpass
fichier (voir Section 32.15).
Le manuel sur psql
:
Un conninfo
string est une alternative pour spécifier les paramètres de connexion :
$ psql "user=myuser password=secret_pw host=localhost port=5432 sslmode=require"
Ou un URI , qui est utilisé à la place d'un nom de base de données :
$ psql postgresql://myuser:[email protected]:5432/mydb?sslmode=require
Fichier de mot de passe
Mais il est généralement préférable de mettre en place un .pgpass
fichier plutôt que de mettre des mots de passe dans des fichiers de script.
Lisez attentivement le court chapitre du manuel. En particulier, notez qu'ici ...
Un nom d'hôte
localhost
correspond à la fois à TCP (nom d'hôtelocalhost
) et socket de domaine Unix (pghost
vide ou le répertoire de socket par défaut) connexions provenant de la machine locale.
Le chemin exact dépend du système. Ce fichier peut stocker des mots de passe pour plusieurs combinaisons de rôle et de port (cluster DB) :
localhost:5432:*:myadmin:myadminPasswd
localhost:5434:*:myadmin:myadminPasswd
localhost:5437:*:myadmin:myadminPasswd
...
Sous Windows les machines recherchent le fichier dans :
%APPDATA%\postgresql\pgpass.conf
%APPDATA%
se résout généralement en :C:\Documents and Settings\My_Windows_User_Name\Application Data\
.