Czytaj dalej, najlepsze opcje są ostatnie . Ale najpierw wyjaśnijmy kilka rzeczy.
Wycisz tylko żądanie hasła
Jeśli Twoim problemem jest tylko pytanie o hasło, możesz je wyciszyć. Cytuję instrukcję tutaj:
-w --no-password
Nigdy nie pytaj o hasło. Jeśli serwer wymaga uwierzytelnienia hasłem, a hasło nie jest dostępne w inny sposób, np. .pgpass plik, próba połączenia nie powiedzie się. Ta opcja może być przydatna w zadaniach wsadowych i skryptach, w których nie ma użytkownika, który mógłby wprowadzić hasło. (...)
Prawdopodobnie nie potrzebujesz hasła
Zwykle jest to niepotrzebne. Domyślny superużytkownik bazy danych postgres zwykle odpowiada użytkownikowi systemu o tej samej nazwie. Uruchamianie psql z tego konta nie wymaga hasła, jeśli metoda uwierzytelniania peer lub ident są ustawione w pliku pg_hba.conf plik. Prawdopodobnie masz taką linię:
local all postgres peer
I zwykle także:
local all all peer
Oznacza to, że każdy lokalny użytkownik może zalogować się do wszystkich bazy danych jako użytkownik bazy danych o tej samej nazwie bez hasła.
Jednak , istnieje tutaj powszechne nieporozumienie. Cytując ponownie:
Ta metoda jest obsługiwana tylko w przypadku połączeń lokalnych .
Pogrubiony nacisk na kopalnię.
Łączysz się z localhost , który nie jest „połączeniem lokalnym” , mimo że zawiera słowo „lokalny”. Jest to połączenie TCP/IP z 127.0.0.1. Wikipedia na lokalnym hoście:
W nowoczesnych systemach komputerowych localhost jako nazwa hosta przekłada się na adres IPv4 w 127.0.0.0/8 (loopback) blok sieciowy, zwykle 127.0.0.1 lub ::1 w IPv6.
Proste rozwiązanie dla połączeń lokalnych
Pomiń parametr -h z psql wezwanie. Cytując instrukcję na psql jeszcze raz:
Jeśli pominiesz nazwę hosta, psql połączy się przez gniazdo domeny Unix do serwera na lokalnym hoście lub przez TCP/IP do localhost na maszynach, które nie mają gniazd domeny Unix.
Okna
... nie ma gniazd domeny Unix, pg_hba.conf linie zaczynające się od local nie mają zastosowania w systemie Windows. W systemie Windows łączysz się przez localhost domyślnie, co prowadzi nas z powrotem do początku.
Jeśli twoje wymagania dotyczące bezpieczeństwa są luźne, możesz po prostu zaufać wszystkim połączeniom przez localhost :
host all all 127.0.0.1/32 trust
Zrobiłbym to tylko w przypadku debugowania z wyłączonymi połączeniami zdalnymi. Dla większego bezpieczeństwa możesz użyć uwierzytelniania SSPI w systemie Windows. Dodaj tę linię do pg_hba.conf dla połączeń „lokalnych”:
host all all 127.0.0.1/32 sspi
Jeśli rzeczywiście potrzebujesz hasła
możesz ustaw zmienną środowiskową , ale jest to odradzane , zwłaszcza dla Windows. Instrukcja:
PGPASSWORD zachowuje się tak samo jak parametr połączenia hasła. Użycie tej zmiennej środowiskowej nie jest zalecane ze względów bezpieczeństwa, ponieważ niektóre systemy operacyjne pozwalają użytkownikom innym niż root przeglądać zmienne środowiskowe procesu za pośrednictwem ps; zamiast tego rozważ użycie ~/.pgpass plik (patrz sekcja 32.15).
Instrukcja dotycząca psql :
conninfo string jest alternatywą dla określenia parametrów połączenia:
$ psql "user=myuser password=secret_pw host=localhost port=5432 sslmode=require"
Lub URI , który jest używany zamiast nazwy bazy danych:
$ psql postgresql://myuser:[email protected]:5432/mydb?sslmode=require
Plik z hasłami
Ale zwykle lepiej jest skonfigurować .pgpass plik zamiast umieszczać hasła w plikach skryptów.
Przeczytaj uważnie krótki rozdział w podręczniku. W szczególności zwróć uwagę, że tutaj ...
Nazwa hosta localhost pasuje do obu TCP (nazwa hosta localhost ) i gniazdo domeny Unix (pghost pustym lub domyślnym katalogiem gniazda) przychodzącymi z lokalnej maszyny.
Dokładna ścieżka zależy od systemu. Ten plik może przechowywać hasła dla wielu kombinacji roli i portu (klaster DB):
localhost:5432:*:myadmin:myadminPasswd
localhost:5434:*:myadmin:myadminPasswd
localhost:5437:*:myadmin:myadminPasswd
...
W Windowsie maszyny szukają pliku w:
%APPDATA%\postgresql\pgpass.conf
%APPDATA% zwykle kończy się na:C:\Documents and Settings\My_Windows_User_Name\Application Data\ .
