Postgresql

Аутентификация только для определённых URL¶

Эта статья предполагала, что вы хотите искать аутентификацию в
каждом запросе. Но в некоторых ситуациях (как в потоке OAuth), вам нужно
на самом деле искать информацию аутентификации только тогда, когда пользователь
достиг определённого URL (например, URL перенаправления в OAuth).

К счастью, справиться в этой ситуацией легко: просто проверьте, какой текущий URL
перед тем, как создавать токен в :

// src/Security/ApiKeyAuthenticator.php

// ...
use Symfony\Component\Security\Http\HttpUtils;
use Symfony\Component\HttpFoundation\Request;

class ApiKeyAuthenticator implements SimplePreAuthenticatorInterface
{
    protected $httpUtils;

    public function __construct(HttpUtils $httpUtils)
    {
        $this->httpUtils = $httpUtils;
    }

    public function createToken(Request $request, $providerKey)
    {
        // установите один URL, где мы должны искать информацию авторизации
        // и возвращать токен только, если мы на этом URL
        $targetUrl = '/login/check';
        if ($request->getPathInfo() !== $targetUrl)
            return;
        }

        // ...
    }
}

Вот и всё! Повеселитесь!

Параметры и конфигурационные файлы

Узнать расположение конфигурационного файла (как правило, размещается по пути: ) можно с помощью:

SHOW config_file;

Узнать значение какого-либо параметра Postgres:

SHOW параметр;

Получить расширенную информацию о параметре можно из представления : будет выведено не только установленное значение, но также файл, в котором он назначен, максимальные и минимальные значения.

SELECT * FROM pg_settings WHERE name = 'параметр';
 
# Например:
SELECT * FROM pg_settings WHERE name = 'max_connections';

Чтобы вывести информацию в удобном для восприятия формате, можно сменить представление командой \x:

Basic HTTP Authentication

Чтобы создать проверку пользователя во всплывающем окне достаточно
следующего кода:

Тем не менее, желательно добавить немного функционала:

Работать такой код будет довольно убого — если ввести пароль неверно не
будет второй попытки. Придётся закрывать вкладку, идти в историю браузера и удалять
там соответствующие данные.

Firefox

это Library → History → Clear Recent History → Active Logins

В Chrome это
Passwords and other sing-in data (в Clear browsing data → Advanced)

В Safari это Clear History

Если пароль поменялся, пользователя со старым паролем не выкинет и т.д.

Примечание о совместимости

Пожалуйста, будьте осторожны при кодировании строк заголовка HTTP.

Чтобы гарантировать максимальную совместимость со всеми клиентами, ключевое слово «Basic» должно быть написано с прописной буквой «B», строка realm должна быть заключена в двойные (а не одинарные) кавычки, и ровно один пробел должен предшествовать коду 401 в строке заголовка HTTP/1.0 401. Параметры аутентификации должны быть разделены запятыми, как показано в приведенном выше примере дайджеста.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

авторизация Twitter

В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.

Amazon Web Services

авторизация Amazon

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Авторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

Установка PostgreSQL на Linux (Mint)

Для подключения к базе данных PostgreSQL понадобится установленный PostgreSQL клиент:

sudo apt install postgresql-client-<VERSION>

Например:

sudo apt install postgresql-client-12

Для установки PostgreSQL сервера:

sudo apt install postgresql

Проверим, можем ли мы подключиться к базе данных PostgreSQL:

sudo -u postgres psql -c "SELECT version();"

Вывод команды должен быть примерно таким:

$ sudo -u postgres psql -c "SELECT version();"
                                                                version                                                                 
----------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit
(1 row)

Клонирование базы данных

Время от времени приходится создавать миграции для баз данных. Процесс разработки такой миграции полон боли и ошибок, а это значит, что я создаю их итерационно, проверяя каждую написанную команду. Я накатываю и откатываю миграцию много раз, убеждаясь что ничего не ломается.

Локальная база данных, на которой я тренируюсь, обычно заполнена вручную или восстановлена из дампа с прода. Т.к. я гоняю преобразование схемы много раз, то обязательно случается, что данные приходят в некорректное состояние. В таком случае я восстанавливаю базу из дампа, что может отнимать достаточно много времени.

В данном случае проще будет воспользоваться клонированием базы данных, а если что-то пойдёт не так, то восстановить из бэкапа. Благо это делается в пару строчек. Для копирования достаточно указать существующую в качестве шаблона.

Для восстановления удалим существующую и склонируем обратно.

Настройка psql

psql отлично настроена и из коробки, однако я бы хотел остановиться на 2х вещах, которые использую каждый день и которые делают psql более удобным инструментом

Первая по важности — получение более удобочитаемового вывода. По умолчанию psql старается представить данные как таблицу:

Пока ширина таблицы меньше ширины экрана всё нормально, но потом строки начнут переноситься и вывод станет просто отвратительным:

Чтобы избежать этого воспользуемся командой активации “расширенного дисплея” (expanded display):

Теперь запрос будет выводиться в две колонки: в первой имя поля, во второй значение.

Ещё одна хитрость: можно включать такой режим только когда он действительно нужен (). В таком случае если таблица помещается по ширине, то будет табличный вывод, в противном случае — построчный.

Вторая возможность — указать как будет выводиться значение NULL. По умолчанию оно неотличимо от пустой строки.

Это можно исправить задав в psql символ для визуализации: . Теперь можно быть уверенным, что если в строке пусто, то это пустая строка, а не NULL.

Хотел бы рассказать ещё об одной фиче psql. Если вам, как и мне, нравятся SQL выражения в ALL-CAPS, то это можно настроить в автодополнении командой . Теперь, когда будете набирать SQL-запрос, последовательность будет автоматически преобразовываться в .

Конечно, прописывать все эти команды каждый раз при запуске psql будет слишком утомительным, так что я предлагаю прописать их один раз в ~/.psqlrc, который выполняется при каждой новой сессии psql.

Это лишь самая малость команд для настройки psql. Гораздо больше вы можете найти в th и psql’s doc.

Можно ли взломать Kerberos?

Хотя Kerberos по-прежнему является самым безопасным протоколом, его можно взломать, как и любой другой. Kerberos, долгое время выступавший в качестве отраслевого стандарта, дал хакерам достаточно времени для преодоления системы.

Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:

Pass-the-ticket: этот метод создает ложный сеансовый ключ путем подделки ложного TGT. Затем хакер может представить TGT службе как действительные учетные данные. Наличие сеансового ключа позволяет этой подделке обходить все этапы проверки Kerberos, которые предшествуют этапу предоставления сеансового ключа.
Золотой билет: этот метод подделывает билет со статусом администратора. Хакер имеет неограниченный доступ ко всему домену при использовании этого билета; доступны отдельные устройства, серверы, данные и настройки. Хакеры могут создать «золотой билет» только в том случае, если у них есть доступ к машине администратора, обычно через установленное вредоносное ПО.
Серебряный билет: Подобно атаке Золотого билета, серебряные билеты — это поддельный билет проверки подлинности службы, который предоставляет доступ к службе. Этот метод дает меньший доступ, чем атака по золотому билету, но его также труднее обнаружить. Все взаимодействия на этом этапе являются взаимодействиями клиент / служба, что позволяет хакеру избежать мер безопасности, установленных в KDC.
Грубая сила: самый очевидный метод, грубая форсировка, включает использование автоматического подбора паролей для ввода тысяч паролей до тех пор, пока не будет найден правильный. Для брутфорса не требуются украденные учетные данные, но его легко обнаружить из-за нечеловеческого поведения при входе.
Вредоносное ПО с скрытым ключом бэкдора : в этом методе хакеры устанавливают скрытый ключ-ключ доступа к бэкдору в систему, чтобы позволить им войти в систему как любой пользователь в любое время в будущем. Этот метод требует ранее успешной атаки Golden Ticket Attack, поскольку эти скелетные ключи могут быть установлены только с административным доступом. Это одни из самых сложных атак для обнаружения, поскольку взлом и атака могут произойти с разницей в годы.

Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу

Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. Пользователям не удается войти на удаленные рабочие столы.

Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.

Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows).

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов.
При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

Создайте сертификаты

PostgreSQL имеет встроенную поддержку использования SSL-соединений для шифрования связи клиент / сервер для повышения безопасности. Если у вас нет приобретенных сертификатов, создайте сертификат сервера, подлинность которого может быть подтверждена клиентами. Для этого сначала создайте запрос на подпись сертификата (CSR) и файл открытого / закрытого ключа, например:

Убедитесь, что вы изменили « root.infoit.com » в соответствии с вашим доменным именем. После создания корневого ключа убедитесь, что для него установлены максимально безопасные разрешения. Убедитесь, что « группа » и « другие » не смогут читать, писать и выполнять..

После этого подпишите запрос ключом для создания корневого центра сертификации (используя расположение файла конфигурации OpenSSL по умолчанию в Linux). Вы можете проверить расположение файла конфигурации OpenSSL в Linux, выполнив команду « openssl version -d »..

Наконец, создайте сертификат сервера, подписанный новым корневым центром сертификации:

Затем также создайте сертификат сервера, подписанный новым корневым центром сертификации.

Приведенные выше команды создадут server.crt и server.key . Это сертификаты серверов, которые мы будем добавлять в PostgreSQL. С другой стороны, root.crt должен храниться на клиенте, чтобы клиент мог убедиться, что сертификат сервера был подписан его доверенным корневым сертификатом. Теперь root.crt должен быть встроен в ваши приложения, написанные на Java и любом другом языке программирования. Для Java это должно быть добавлено в хранилище ключей .

Храните root.key в безопасном месте, чтобы его можно было использовать при создании будущих сертификатов.

Для удобства скопируем серверный и корневой сертификаты в место, где PostgreSQL хранит свои основные файлы конфигурации. Таким образом, Postgres сможет читать их в том же месте, где он читает свои файлы конфигурации.

Расположение в CentOS /var/lib/pgsql/13/data/ для PostgreSQL 13 и, /var/lib/pgsql/12/data/ для PostgreSQL 12 /var/lib/pgsql/11/data/ для PostgreSQL 11. В этом примере мы будем использовать PostgreSQL 11.

Работа с шаблонами баз данных

При установке PostgreSQL по умолчанию создаются три базы данных: postgres, template0, template1.

Template0 и template1 — это шаблоны баз данных, из которых в дальнейшем будут создаваться пользовательские БД.

Фактически, когда вы выполняете команду CREATE DATABASE, Postgres создает клон базы template1. Если внести изменения в template1, они будут наследоваться всеми новыми создаваемыми базами. Это позволяет, например, добавить в template1 необходимые вам таблицы с данными или установить расширения, после чего не потребуется добавлять их для каждой новой базы.

Обратите внимание, что для установки расширений необходимо подключиться к template1 от суперпользователя (postgres или другой роли, имеющей данные привилегии). Подключитесь к шаблону template1:

Подключитесь к шаблону template1:

\c template1

И установите расширение:

CREATE EXTENSION название_расширения;

Например, если вы установите в template1 расширение pgcrypto, то в дальнейшем, при выполнении CREATE DATABASE, новые базы будут создаваться с уже установленным pgrypto.

Template0 — это исходная база, которая используется, когда нужно создать новую базу без каких-либо изменений, внесенных в шаблон template1, или же вернуть template1 в его изначальное состояние.

Чтобы создать «чистую» базу на основе template0, нужно выполнить:

CREATE DATABASE имя_базы TEMPLATE template0;

Также template0 необходима, если вам нужно внести изменения в кодировку или локаль создаваемой базы данных. По умолчанию (при использовании template1) эти изменения невозможны.

В этом случае нужно при создании базы указать template0 в качестве шаблона и указать требуемую кодировку и/или локаль, например:

CREATE DATABASE имя_базы TEMPLATE template0 ENCODING 'SQL_ASCII';

Пересоздание template1

С помощью template0 вы также можете вернуть базу template1 в исходный вид: для этого потребуется ее удалить, а после создать заново, на основе шаблона template0.

Сначала необходимо указать, что template1 не является шаблоном, чтобы удаление стало возможно:

UPDATE pg_database SET datistemplate = false WHERE datname = 'template1';

Далее удалить template1:

DROP DATABASE template1;

И создать базу template1 заново, указав, что она будет являться шаблоном:

CREATE DATABASE template1 OWNER postgres TEMPLATE template0 is_template true;

Разбивка процесса Kerberos (16 шагов)

Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:

1. Войти

Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.

2. Запросы клиентов на сервер выдачи билетов

Затем клиент отправляет серверу аутентификации текстовое сообщение, содержащее:

введенное имя пользователя
название запрашиваемой услуги
сетевой адрес пользователя
как долго они запрашивают доступ на

3. Сервер проверяет имя пользователя.

Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.

4. Выдача билета. Билет возвращается клиенту.

Сервер аутентификации отправляет клиенту два зашифрованных сообщения:

Message A может быть расшифрован с помощью секретного ключа клиента, созданного на шаге 1. Он содержит имя TGS, временную метку, время жизни билета и вновь предоставленный сеансовый ключ сервера предоставления билетов.
Message Bявляется билетом на выдачу билета и может быть расшифрован только с помощью секретного ключа TGS. Он содержит ваше имя пользователя, имя TGS, метку времени, ваш сетевой адрес, время жизни билета и тот же ключ сеанса TGS.

5. Клиент получает сеансовый ключ TGS.

Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.

6. Клиент запрашивает доступ к службе с сервера

Теперь клиент отправляет обратно два сообщения:

Message Cпредставляет собой незашифрованное сообщение, содержащее имя запрошенной службы, время существования и все еще зашифрованное message B.
Message D является аутентификатором, зашифрованным с помощью сеансового ключа TGS, и содержит ваше имя и временную метку

7. Сервер проверяет службу.

Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.

8. Сервер получает сеансовый ключ TGS.

Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.

Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.

Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.

9. Сервер генерирует служебный сеансовый ключ.

Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.

Message E зашифрован с помощью секретного ключа службы и содержит ваше имя, имя запрошенной службы, метку времени, ваш сетевой адрес, время жизни билета и ключ сеанса службы.
Message Fшифруется с помощью сеансового ключа TGS, хранимого как клиентом, так и сервером. Это сообщение содержит всю ту же информацию, message Eкроме вашего имени пользователя и сетевого адреса.

10. Клиент получает ключ сеанса обслуживания.

Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.

11. Клиент связывается с Сервисом

Теперь клиент отправляет еще два сообщения, на этот раз службе:

Message G- еще одно сообщение аутентификатора, на этот раз зашифрованное с помощью сеансового ключа службы. Он содержит ваше имя и метку времени.
Message Hявляется копией message E, которая все еще зашифрована служебным секретным ключом.

12. Расшифровка сервисов Message G

Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.

13. Сервис проверяет запрос

Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.

14. Сервис аутентифицируется для клиента.

Затем служба отправляет message Iзашифрованные с помощью сеансового ключа службы, хранимого как службой, так и клиентом. Message I- аутентификатор, содержащий идентификатор службы и временную метку.

15. Клиент проверяет услугу.

Затем клиент расшифровывает, message Iиспользуя ключ сеанса службы, кэшированный с шага 10. Затем клиент проверяет идентификатор и временные метки, содержащиеся в нем. Если оба соответствуют ожидаемым результатам, услуга считается безопасной.

16. Свободное общение между клиентом и службой

Уверенный в том, что и клиент, и служба взаимно аутентифицированы, Kerberos позволяет клиенту связываться со службой.

Что такое политики защиты строк

Привилегии для ролей определяют доступ к целым табличкам, или к столбцам. Идея защиты строк состоит в том, чтобы разграничивать доступы к разным строчкам. В документации про этот механизм можете почитать тут.

Пишется специальное логическое выражение и вычисляется для каждой строки. Если такое выражение истинно, то мы видим строку, а в противном случае не видим. Такое выражение называют предикатом.

Один предикат применяется для существующих строк и используется командами:

SELECT
UPDATE
DELETE

По умолчанию, если предикат возвращает ложь, то никакой ошибки не будет. Просто делается вид, что этой строчки в таблице нет. Это поведение можно изменить сбросив параметр row_security.

Второй предикат применяется для новых строк и используется командами:

INSERT
UPDATE

При работе второго предиката, если он возвращает значение ложь, то появляется ошибка. Ошибка говорит нам, что у нас нет права доступа вставить или обновить определённую строку.

Эти предикаты работают в дополнение к привилегиям. Сначала проверяются ваши привилегии на объект, а затем еще и предикаты, если они у вас используются. По умолчанию политики защиты строк выключены.

пример

Здесь я приведу пример одноранговой аутентификации

Смысл этой конфигурации:Когда клиент использует сокет unix для подключения к базе данных, используется идентификация с использованием идентификатора. Когда пользователь клиентской ОС использует digoal, ему разрешается подключаться к базе данных как пользователь базы данных postgres.

Когда подключенного пользователя базы данных нет на карте, выдается сообщение об ошибке.

pg_ident.conf также поддерживает регулярные выражения.https://www.postgresql.org/docs/9.6/static/auth-username-maps.html

Метод идентификатора немного сложнее. Вам необходимо развернуть сервер идентификатора на клиенте. Для настройки обратитесь к следующим документам.https://wiki.archlinux.org/index.php/Identd_Setup

Пользователи (роли)

Вместо привычного понятия пользователей, PostgreSQL использует концепцию ролей. Несмотря на определенные отличия, в целом можно определять роли как пользователей базы данных.

В зависимости от настройки, роль можно рассматривать как пользователя базы данных или как группу пользователей. Роли могут владеть объектами базы данных (например, таблицами) и выдавать другим ролям разрешения на доступ к этим объектам. Также можно предоставить одной роли членство в другой роли (схоже с добавлением пользователя в группу), чтобы одна роль могла использовать привилегии другой роли.

Как отмечалось выше, во время установки была автоматически создана роль postgres. Вы можете работать с СУБД из-под нее. Для этого переключитесь на сессию данного пользователя:

sudo su - postgres

После чего запустите консоль Postgres:

psql

После завершения работы вы сможете выйти из консоли Postgres командой :

postgres=# \q

Так как для каждой созданной роли Postgres предполагает наличие базы данных с таким же именем и по умолчанию подключается именно к ней, имеет смысл создавать новую роль для каждой базы. Кроме того, если имя роли совпадает с именем пользователя, созданного в системе Linux, подключение к БД также упрощается.

Создание новой роли

Создать роль из консоли системы (не psql) можно с помощью команды:

createuser -P --interactive

Ключ позволит сразу задать пароль пользователю, а запустит интерактивный режим для указания дополнительных параметров.

Система поочередно запросит имя новой роли, ее пароль и повтор пароля, а также позволит указать привилегии: сделать ли роль суперпользователем, должны ли быть права на создание баз данных и создание других ролей. Нажимайте y / n и Enter для выбора.

Создать роль из консоли Postgres можно с помощью команды CREATE ROLE.

При использовании этой команды без дополнительных опций пользователь будет создан без каких-либо привилегий, поэтому желательно сразу при создании роли указывать нужные привилегии. Полный список доступных опций можно просмотреть, выполнив:

\h CREATE ROLE

Чтобы создать новую роль выполните:

CREATE ROLE имя_роли WITH LOGIN CREATEDB CREATEROLE;

Далее задайте новому пользователю пароль:

\password имя_роли

Просмотр существующих ролей

Чтобы просмотреть созданных пользователей и их привилегии, перейдите в консоль Postgres:

psql

И выполните команду:

\du

Пример вывода:

                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 tmweb     | Create role, Create DB                                     | {}
 tweb      | Create role, Create DB                                     | {}

Нажмите q, чтобы закрыть вывод, и \q, если нужно выйти из консоли Postgres.

dropuser имя_роли

Либо команду в консоли Postgres:

DROP ROLE имя_роли;

Смена пароля пользователя

Для смены пароля одной из ролей подключитесь к Postgres от суперпользователя (postgres или другой роли с такими привилегиями), после чего выполните:

ALTER USER имя_роли WITH PASSWORD 'новый_пароль';

Обратите внимание, что эта операция сохранится в файле вместе с паролем в открытом виде. Из соображений безопасности рекомендуется удалить соответствующую запись из файла

Как правило, файл размещается в директории . Проверить его расположение можно в терминале системы с помощью:

grep postgres /etc/passwd | cut -d ':' -f 6

Откройте файл, указав корректный путь к нему:

sudo nano /var/lib/postgresql/.psql_history

Удалите запись с паролем и сохраните изменения.

Параметры подключения

Теперь рассмотрим параметры подключений!

Типы подключений:

local – использует unix сокет;
host – использует TCP/IP, оно может быть шифрованным с помощью SSL или не шифрованным;
hostssl – только зашифрованный TCP/IP;
hostnossl – только не зашифрованный TCP/IP.

Имя базы данных:

all – подключение к любой БД;
sameuser – БД, совпадающая по имени с ролью;
samerole – БД, совпадающая по имени с ролью или группой, в которую она входит;
replication – специальное разрешение для протокола репликации;
имя базы данных – имя конкретной базы данных, или через запятую можно перечислить список баз данных.

Адрес узла:

all – любой IP-адрес;
ip-адресс – конкретный ip адрес, подсеть, или диапазон (172.20.143.0/24 или 172.20.143.0 255.255.255.0)
samehost – означает адрес сервера с которого ведётся подключение, аналог 127.0.0.1;
samenet – означает любой ip адрес из подсети сервера;
доменное имя (или часть доменного имени, начиная с точки) – при этом postgresql проверяет ip-адрес подключающегося клиента на принадлежность к этому домену.

Имя роли:

all – любая роль;
<имя роли> – роль с указанным именем, при этом можно перечислить роли через запятую;
+<имя роли> – групповая роль, в которую включены другие роли.

Тип аутентификации:

Аутентификация без проверок:
- trust – разрешает подключение без аутентификации, то есть без проверки пароля или любых других проверок;
- reject – запрещает подключение ничего не проверяя;
Аутентификация по паролю:
- md5 – пароль хранится в СУБД и шифруется MD5;
- scram-sha-256 – пароль хранится в СУБД, используется протокол SCRAM (более надёжно);
- ldap – пароль хранится на сервере LDAP;
- radius – пароль хранится на сервере RADIUS;
- pam – пароль хранится в подключаемом модуле PAM;
Внешняя аутентификация:
- peer – запрашивает имя пользователя у операционной системы (только для Linux и только для локальных подключений);
- cert – аутентификация с использованием клиентского SSL-сертификата;
- gss – аутентификация Kerberos по протоколу GSSAPI;
- sspi – аутентификация Kerberos/NTLM для Windows.

Сценарии проверки подлинности

Проверка подлинности Windows обычно является лучшим выбором в следующих ситуациях:

Есть контроллер домена.
Приложение и база данных находятся на одном компьютере.
Используется экземпляр SQL Server Express или LocalDB.

Имена для входа SQL-сервера часто используются в следующих ситуациях:

Если у вас есть рабочая группа.
Пользователи соединяются из разных, ненадежных доменов.
Существуют интернет-приложения, такие как ASP.NET.

Примечание

При использовании аутентификации Windows имена входа SQL Server не отключаются. Чтобы отключить имена входа SQL Server с правами доступа, используйте инструкцию Transact-SQL ALTER LOGIN DISABLE.

Создать базу данных

Создадим базу данных
heihei_ru_db
с кодировкой utf8

CREATE DATABASE «heihei_ru_db» WITH OWNER «postgres» ENCODING ‘UTF8’;

CREATE DATABASE

Создадим базу данных heihei с кодировкой utf8 и укажем значения для Collate, Ctype и Template

CREATE DATABASE «heihei» WITH OWNER «postgres» ENCODING
‘UTF8’ LC_COLLATE = ‘C’ LC_CTYPE = ‘C’ TEMPLATE = template0;

CREATE DATABASE

Проверим, что получилось

Если я в

bash

сделаю

locale -a

То получу сразу четыре доступные кодировки

C.UTF-8

en_US.utf8

POSIX

Но создать БД, например, с en_US.utf8 у меня не получается

CREATE DATABASE «heihei» WITH OWNER «postgres» ENCODING
‘UTF8’ LC_COLLATE = ‘en_US.utf8’ LC_CTYPE = ‘en_US.utf8’ TEMPLATE = template0;

Приводит к ошибке

ERROR: invalid locale name: «en_US.UTF-8»

UPD: Выполнил такую же команду в

Ubuntu

и база успешно создана

CREATE DATABASE «new_db» WITH OWNER «postgres» ENCODING ‘UTF8’ LC_COLLATE = ‘en_US.UTF-8’ LC_CTYPE = ‘en_US.UTF-8’ TEMPLATE = template0;

CREATE DATABASE

Снова за свое

В одной из прошлых статей был предложен небольшой набор скриптов для SQL Server, позволяющий оценить текущее состояние сервера, узнать какие базы на нем расположены и другую полезную информацию. Сегодня мы попытаемся сделать то же самое для PostgreSQL. Ведь все любят PostgreSQL, не так ли?

Информация будет полезна для администраторов и разработчиков, имеющих дело с хайповой СУБД, а также всем энтузиастам, желающих «пощупать» PostgreSQL. Мы пройдем примерно такой же путь, что проделывали для SQL Server, но с некоторыми существенными отличиями, ведь обе СУБД значительно отличаются в архитектуре и принципах функционирования.

Здесь Вы не найдете продвинутых скриптов, ведь это лишь для знакомство с новым серверов PostgreSQL. Но обо всем далее.