Продължавайте да четете,най-добрите опции идват на последно място . Но нека първо изясним няколко неща.
Само заглушаване на заявката за парола
Ако проблемът ви е само в подкана за парола, можете да го заглушите. Цитирам ръководството тук:
-w
--no-password
Никога не издавайте подкана за парола. Ако сървърът изисква удостоверяване с парола и парола не е налична по други средства, като например
.pgpass
файл, опитът за свързване ще бъде неуспешен. Тази опция може да бъде полезна при пакетни задания и скриптове, където няма потребител, който да въведе парола. (...)
Вероятно нямате нужда от парола
Обикновено това е ненужно. Суперпотребител на база данни по подразбиране postgres
обикновено съответства на системния потребител със същото име. Изпълнява се psql
от този акаунт не изисква парола, ако методът за удостоверяване peer
или ident
са зададени във вашия pg_hba.conf
файл. Вероятно имате ред като този:
local all postgres peer
И обикновено също:
local all all peer
Това означава, всеки местен потребителят може да влезе в всички база данни като потребител на база данни със същото име без парола.
Въпреки това , тук има често срещано погрешно схващане. Отново цитирам:
Този метод се поддържа само при локални връзки .
Удебелен акцент моето.
Вие се свързвате с localhost
, коетоне е "локална връзка" , въпреки че в него има думата "местен". Това е TCP/IP връзка към 127.0.0.1. Уикипедия на локален хост:
В съвременните компютърни системи
localhost
като име на хост се превежда в anIPv4 адрес в127.0.0.0/8
(loopback) мрежов блок, обикновено127.0.0.1
, или::1
в IPv6.
Просто решение за локални връзки
Пропуснете параметъра -h
от psql
призоваване. Цитирам ръководството за psql
още веднъж:
Ако пропуснете името на хоста, psql ще се свърже чрез Unix-домейн сокет към сървър на локалния хост или чрез TCP/IP към
localhost
на машини, които нямат сокети на Unix домейн.
Windows
... няма сокети на Unix домейн, pg_hba.conf
редове, започващи с local
не са приложими в Windows. В Windows се свързвате чрез localhost
по подразбиране, което ни връща към началото.
Ако изискванията ви за сигурност са слаби, можете просто да се доверите на всички връзки чрез localhost
:
host all all 127.0.0.1/32 trust
Бих направил това само за отстраняване на грешки с изключени отдалечени връзки. За по-голяма сигурност можете да използвате SSPI удостоверяване в Windows. Добавете този ред към pg_hba.conf
за "локални" връзки:
host all all 127.0.0.1/32 sspi
Ако наистина имате нужда от парола
Вие можете задайте променлива на средата , но това еобезкуражено , особено за Windows. Ръководството:
PGPASSWORD
се държи по същия начин като параметъра за връзка с парола. Използването на тази променлива на средата не се препоръчва от съображения за сигурност, тъй като някои операционни системи позволяват на потребителите без root права да виждат променливите на средата на процеса чрез ps; вместо това помислете за използването на~/.pgpass
файл (вижте раздел 32.15).
Ръководството за psql
:
conninfo
string е алтернатива за определяне на параметри на връзката:
$ psql "user=myuser password=secret_pw host=localhost port=5432 sslmode=require"
Или URI , което се използва вместо име на база данни:
$ psql postgresql://myuser:[email protected]:5432/mydb?sslmode=require
Файл с парола
Но обикновено е за предпочитане да настроите .pgpass
файла вместо да поставяте пароли в скриптови файлове.
Прочетете внимателно кратката глава в ръководството. По-специално, имайте предвид, че тук ...
Име на хост
localhost
съвпада и с двата TCP (име на хостlocalhost
) и Unix домейн сокет (pghost
празна или директория на сокет по подразбиране) връзки, идващи от локалната машина.
Точният път зависи от системата. Този файл може да съхранява пароли за множество комбинации от роля и порт (DB клъстер):
localhost:5432:*:myadmin:myadminPasswd
localhost:5434:*:myadmin:myadminPasswd
localhost:5437:*:myadmin:myadminPasswd
...
На Windows машините търсят файла в:
%APPDATA%\postgresql\pgpass.conf
%APPDATA%
обикновено се разрешава до:C:\Documents and Settings\My_Windows_User_Name\Application Data\
.