Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Зачем?
Например, я у себя сделал отправку СМС прямо из PostgreSQL с помощью REST интерфейса оператора, а также регистрацию чеков в ОФД тоже с помощью REST интерфейса провайдера
но зачем?
Использую нечто подобное (отправка e-mail) на одной из моих систем. Тикая фишка важна для обеспечения высокой безопасности системы.
В конкретном моем случае есть PHP frontend и PostgreSQL. Каждый запрос пользователя требующий обращения к базе данных происходит используя логином и паролем самого пользователя (Login/Password WEB = Login/Password DB). Со стороны базы обеспечен ROW-level security: пользователь видит только свои записи в базе и ничего более, и записи может менять только через функции. Такой подход довольно трудоемкий и требует вдумчивого дизайна поэтому на практике встречается довольно редко. Одна из «проблемных» фишек в такой архитектуре — возможность пользователю сбросить свой пароль если «забыл» старый. Соображения безопасности не позволяют отдать какую функциональность в frontend так как это подразумевало-бы наличие у PHP доступа с аккаунту «суперпользователя» что полностью подрывает архитектуру безопасности (полный/частичный взлом frontend не должен быть критичным для функционирования всей системы или, тем более, не должен давать доступа к данным пользователей). Соответственно ResetCode, а после подтверждения, и временный Password отсылаются пользователю напрямую из PostgreSQL.
При таком подходе, для полного взлома, злоумышленнику нужно взять под свой контроль множество гетерогенных систем, что, скажем так, как минимум не тривиально.
В конкретном моем случае есть PHP frontend и PostgreSQL. Каждый запрос пользователя требующий обращения к базе данных происходит используя логином и паролем самого пользователя (Login/Password WEB = Login/Password DB). Со стороны базы обеспечен ROW-level security: пользователь видит только свои записи в базе и ничего более, и записи может менять только через функции. Такой подход довольно трудоемкий и требует вдумчивого дизайна поэтому на практике встречается довольно редко. Одна из «проблемных» фишек в такой архитектуре — возможность пользователю сбросить свой пароль если «забыл» старый. Соображения безопасности не позволяют отдать какую функциональность в frontend так как это подразумевало-бы наличие у PHP доступа с аккаунту «суперпользователя» что полностью подрывает архитектуру безопасности (полный/частичный взлом frontend не должен быть критичным для функционирования всей системы или, тем более, не должен давать доступа к данным пользователей). Соответственно ResetCode, а после подтверждения, и временный Password отсылаются пользователю напрямую из PostgreSQL.
При таком подходе, для полного взлома, злоумышленнику нужно взять под свой контроль множество гетерогенных систем, что, скажем так, как минимум не тривиально.
А почему бы не включить какой-нибудь PL/python и через него такие вещи делать?
Как представлю танцы новой команды аутсорсеров над проектом без документации, в котором используется такое решение…
(спустя… часов дебага)
Кто, говорите, письма отправляет? PostgreSQL???
Это ещё что! Я у себя в форке curl добавил поддержку выполнения команд по ssh, и теперь у меня postgres может зайти по ssh на сервак, циску, микротик и выполнять там команды. И всё это асинхронно благодаря планировщику!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рецепты PostgreSQL: cURL: get, post и… email