Что то во мне эти «Декодир.» и «Выполнен.» на рис. 7.45 всколыхнули ностальгию времен наколенного собственноручного перевода Volkov Commander'a на русский язык методом прямой правки COM-файла :)
Но дело нужное и правильное! Заказал. Придется-таки идти в филиал_ада (tm).
Как ниже правильно заметили, только явное указание PDO::PARAM_STR в PDO::bindParam решило бы.
А про '?' — глупость сморозил. Просто практически никогда не связывался с prepared statements в клиентских приложениях.
Потому как в аналогичной ситуации STRICT_ALL_TABLES и прочее нас не спасло.
MySQL знатно неявно кастит числа, да, хотя и услужливо пишет, что за выполнение запроса select * from t where string = 123456 было два предупреждения. Которые по-умолчанию все равно нигде не пишет.
В MySQL не силен нисколько, поэтому не знаю, как там чего реализовано.
Для себя решил, что HBA — это результат попытки разделить ответственность за безопасность между администраторами БД и сисадминами :). Но вообще говоря, RBAC (Role-based auth system) довольно дорогая штука при DoS атаках, а HBA — очень дешевая. Фактически, HBA — это разновидность файрвола.
А вообще, в большинстве своих проектов не залезал в pg_hba.conf. Где это было необходимо (а это доступ к БД через сеть) сперва все равно лезешь в postgresql.conf добавлять интерфейсы в listen_addresses и полностью перезагружаешь кластер. После чего в pg_hba только подкидываются/убираются сети и пользователи, которым разрешен доступ и делается релоад.
Из Security Best Practices могу рекомендовать погуглить 'postgresql security best practices', первые же две ссылки — документы IBM и OpenSCG на эту тему. И там, и там очень хорошо расписано, что зачем.
HBA — это host-based authentication. До есть контроль доступа на уровне файлов (а в UNIX все — файлы).
Если в нем будет разрешено всем все, то да — можно средствами только SQL создать пользователя, доступ у него уже будет.
HBA тут просто как еще один уровень безопасности. В частности с помощью этого механизма пользователь, под которым запущен постгрес на локальной машине с этой же локальной машины может подключаться без ввода пароля через файловый сокет по-умолчанию (во всяком случае, на Debian)
The pg_hba.conf file is read on start-up and when the main server process receives a SIGHUP signal. If you edit the file on an active system, you will need to signal the postmaster (using pg_ctl reload or kill -HUP) to make it re-read the file.
Но дело нужное и правильное! Заказал. Придется-таки идти в филиал_ада (tm).
Как ниже правильно заметили, только явное указание PDO::PARAM_STR в PDO::bindParam решило бы.
А про '?' — глупость сморозил. Просто практически никогда не связывался с prepared statements в клиентских приложениях.
$where = «providerUserId = '?'»;
Потому как в аналогичной ситуации STRICT_ALL_TABLES и прочее нас не спасло.
MySQL знатно неявно кастит числа, да, хотя и услужливо пишет, что за выполнение запроса select * from t where string = 123456 было два предупреждения. Которые по-умолчанию все равно нигде не пишет.
Для себя решил, что HBA — это результат попытки разделить ответственность за безопасность между администраторами БД и сисадминами :). Но вообще говоря, RBAC (Role-based auth system) довольно дорогая штука при DoS атаках, а HBA — очень дешевая. Фактически, HBA — это разновидность файрвола.
А вообще, в большинстве своих проектов не залезал в pg_hba.conf. Где это было необходимо (а это доступ к БД через сеть) сперва все равно лезешь в postgresql.conf добавлять интерфейсы в listen_addresses и полностью перезагружаешь кластер. После чего в pg_hba только подкидываются/убираются сети и пользователи, которым разрешен доступ и делается релоад.
Из Security Best Practices могу рекомендовать погуглить 'postgresql security best practices', первые же две ссылки — документы IBM и OpenSCG на эту тему. И там, и там очень хорошо расписано, что зачем.
Наверное, в MySQL тоже что-то для этого есть.
Если в нем будет разрешено всем все, то да — можно средствами только SQL создать пользователя, доступ у него уже будет.
HBA тут просто как еще один уровень безопасности. В частности с помощью этого механизма пользователь, под которым запущен постгрес на локальной машине с этой же локальной машины может подключаться без ввода пароля через файловый сокет по-умолчанию (во всяком случае, на Debian)
The pg_hba.conf file is read on start-up and when the main server process receives a SIGHUP signal. If you edit the file on an active system, you will need to signal the postmaster (using pg_ctl reload or kill -HUP) to make it re-read the file.