Максим (@myks92)
2021-06-07 12:04
Спасибо!)
Страница входа и Query-модель
Продолжаем интеграцию. Когда у нас готовы сущности и репозитории создадим сам компонент OAuth-сервера. Для него сгенерируем файлы ключей и сделаем их деплой из Jenkins через Docker Secrets. Сделаем страницу входа и контроллер для генерации и обновления токенов. Все контроллеры покроем функциональными тестами.
По аналогии с Command добавим Query-модель на DBAL для выполнения запросов на чтение данных из модуля. И заодно рассмотрим, как можно избавиться от вызова синглтона SentrySDK в коде наших сервисов и экшенов:
- 00:00:43 Работа с Authorization Server
- 00:05:59 Ключи для подписи и шифрования
- 00:07:55 Регистрация Encryption Key
- 00:09:50 Использование Secrets в Docker
- 00:14:28 Деплой файлов из Jenkins
- 00:16:38 Создание авторизационного сервера
- 00:20:43 Функциональные тесты авторизации
- 00:22:49 Тестирование HTML-страниц
- 00:29:41 Ответ для HTML-страниц
- 00:30:51 Вёрстка страницы входа
- 00:31:59 Контроллер для входа
- 00:35:51 Вынос компонента Sentry
- 00:38:16 Избавление от вызова синглтона
- 00:45:05 Команды и запросы
- 00:47:08 Запрос пользователя по паролю
- 00:49:25 Отдельная Query-модель чтения
- 00:53:04 Запросы через DBAL
- 00:55:17 Реализация формы входа
- 01:02:22 Экшен генерации токенов
В следующем эпизоде сделаем аутентификацию для страницы просмотра профиля и добавим Cron-команды в Docker Swarm для очистки старых кодов и токенов.
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Комментарии (26)
v
2021-06-07 15:07
Почему Fetcher из FindIdByCreedintials сам строит запрос в базу данных, а не обращается к UserRepository?
Дмитрий Елисеев
2021-06-07 15:15
Как раз об этом рассказал с 49-ой минуты
Александр
2021-06-07 21:04
Спасибо!
fedot
2021-06-08 08:54
Спасибо!
Arunas
2021-06-08 19:04
Спасибо :)
Артем Астапов
2021-06-22 19:49
Дмитрий, добавляйте пожалуйста ссылки на гайды - например, с сайта developer.okta.com и oauth2.thephpleague.com
slo_nik
2021-10-12 19:13
Добрый вечер, Дмитрий.
Подскажите, пожалуйста, если не использовать docker swarm, можно ли как-то прочитать файлы ключей в контейнере?
Пробовал в docker-compose.yml указать файлы ключей через secrets, но на рабочем сервере не получается прочитать файлы, отказано в доступе.
Права на файлы получаются 0400 и создаются от root.
Я пробовал указать mode в docker-compose.yml, но права на файл не менялись.
secrets:
- source: db_password
target: database_password_secret
mode: 0440
Дмитрий Елисеев
2021-10-19 07:44
Локально мы не используем swarm, но секреты нормально подключаются. Так что странно, что не срабатывает.
slo_nik
2021-10-19 11:25
Да, локально без проблем.
Проблемы на рабочем сервере.
Использование mode не помогло, поискал информацию в инете, но нашёл только то, что эти настройки работают только со swarm-ом, это как бы не полноценная настройка(возможно не так выразился). То есть, как бы я не менял права доступа к файлу через mode, права остаются без изменений.
Вот такими права остаются
-r-------- 1 slonik slonik 1273 мая 30 23:11 phpunit.xml.dist
Ярослав
2021-10-23 10:41
Когда я захожу по адресу localhost:8081/authorize то выбивает ошибку:
Key path "file:///run/secrets/jwt_private_key" does not exist or is not readable
Когда я зашел внутрь контейнера api-php-fpm, то внутри папки /run/secrets вижу такое:
-rw------- 1 1000 1000 1675 Oct 22 12:13 jwt_private_key
-rw-rw-r-- 1 1000 1000 451 Oct 22 12:14 jwt_public_key
Соответственно тесты в файле AuthorizeTest не проходят(там ошибка 500).
И что я не так сделал, я без понятия. Там походу ведь docker-compose должен прокидывать туда эти ключи. Он у меня версии 1.25.0. Может дело в нем?
Ярослав
2021-10-23 12:21
Проблема решена заменой ключей на те, что были в репозитории. Все тесты теперь проходят.
Aёct'ann
2022-07-23 13:38
Проблема в том, что у файла jwt_private_key нет прав на чтение. Когда эти файлы были сгенерированы - у них такие права стоят в целях безопасности. Нужно добавить для этого файла права на чтение, только вот не знаю, группы или для всех... Как вариант:
chmod ugo+r docker/development/secrets/jwt_private.key
Максим
2021-12-31 11:01
Добрый день, и с наступающим новым годом! В данном уроке, Дмитрий, Вы используете чисты Sql. Получается что название таблиц и столбцов помимо маппинга на сущности ещё и будут в каждом таком запросе. Doctrine решает эту проблему с помощью Dql, плюс даёт возможность расширять этот язык. В своем проекте, я как раз пытаюсь уйти от нативного Sql, в пользу языка запросов к доменной модели.
Максим (@myks92)
2022-01-31 03:30
Здравствуйте. Столкнулся инфраструктурной проблемой и ридмоделями.
В объектах домена понятно дело нет всей информации для построения ридмодели.
К примеру нет понятия кем создана заявка - человеком/ботом. Кто владелец данной заявки, кто редактор.
Но нужна ли она бизнесу? Наверное нет, чем да. Но для построения рид модели понадобилась данная информация.
Как быть?
Единственное что я сейчас вижу это metadata у бизнес объектов куда я могу складировать дополнительную информацию. Создать какой-то отдельный контекст для этого и хранить всё там. Почему отдельный контекст? Потому что это не доменная модель. Бизнесу это не нужно в его контексте. Поэтому и портить доменную модель инфраструктурной частью приложения не хочется. Тогда где же хранить подобную информацию?
Ещё есть кейс - Owner. Когда есть владелец, чего-то и на основании этого надо предоставлять права на редактировании. Опять же это не бизнес требование, а предоставление доступа на уровне приложения. Соотвественно опять не хочется портить бизнес слой контекста. Тогда где хранить?
Хотелось бы услышать Ваши мысли. Благодарю!
Дмитрий Елисеев
2022-03-02 15:26
Проще всего хранить прямо в заявке.
Sergey
2022-06-28 22:30
Добрый вечер.
Вопрос по поводу хранения запросов внутри модуля Auth в папке api/src/Auth/Query
Я так понимаю ответственности (функциональность) классов/интерфейсов находящихся внутри папки api/src/Auth должны быть изолированны в рамках этого модуля Auth и не могут напрямую зависеть от классов и данных других модулей (которые наверняка появятся в проекте в ближайшем будущем).
Отсюда вопрос, если появится sql query который будет содержать к примеру джойны (я понимаю что можно обойтись без джойнов и собирать к примеру в контроллере результат из отельных простых queries, но как показывает практика простой join по производительности чаще всего выигрывает) на таблицы других модулей тогда где их хранить? Ведь папка api/src/Auth/Query уже не подходит в этом случае (как и соответствующая папка в внутри другого модуля), так как query будет зависеть в данном случае от таблиц уже разных модулей.
В каком месте вы бы хранили такие queries?
Заранее спасибо за ваше время!
Дмитрий Елисеев
2022-06-29 07:10
Про это как раз делал доклад про модульное разделение. А в общем да, собирать данные из разных модулей в контроллере. А если нужен обобщающий запрос, то положить в отдельную папку.
Sergey
2022-06-29 09:23
Спасибо за быстрый ответ. Ознакомлюсь с докладом
Максим (@myks92)
2022-08-19 11:48
С позволения Дмитрия добавлю ответ. Суть деления на модули как раз и заключается в том чтобы убрать зависимости между модулями, в том числе и по базе данных. Когда хочется сделать такое - представьте, что это разные базы. Один модуль в Redis, второй в PostgreSQL. Либо вам достался проект, где постепенно переходите с Mysql на PostgreSQL. Если вы организуете связанность по Join таблицы, то вы создали неконтролируемую связь. Завтра кто-то захочет удалить модуль или изменить название таблицы, поменять название столбцов и ваш модуль сломается. Поэтому и предлагается на уровне контроллера делать запрос из разных Query. А с какой базы они работают - нам всё равно. Поэтому лучше использовать разные Query в контроллере или интерфейсы для взаимодействия. Но если всё таки хочется сделать такую Query по каким либо причинам не стоит это делать в папке модуля. Мы иногда такие Query выносим в src/Query. По аналогии stc/Http. Таким образом мы контролируем зависимость.
Aёct'ann
2022-07-24 21:46
Доброй ночи! А почему страница для авторизации сделана на стороне "бэка"? Мы же могли ее сделать на фронте и подгружать из реакта?
Дмитрий Елисеев
2022-07-29 08:10
В OAuth так делают специально для безопасности, чтобы логин и пароль вводили только на сервере аутентификации. Если нужен самый безопасный вариант, то туда стоит перенести также регистрацию и восстановление пароля и защитить все формы от CSRF, чтобы фронтенд и другие клиенты вообще не работали с паролями.
Simon
2023-02-03 04:19
Добрый день, Дмитрий. А можно по подробнее про безопасность? Почему мы не можем генерить форму на реакте?
Дмитрий Елисеев
2023-02-07 13:07
Представьте, что на каком-либо чужом сайте или в чужом мобильном приложении вы нажали "Войти через Google", а вам вместо редиректа оно прямо у себя выведет форму: "Введите сюда свой email и пароль от Google".
Я испугаюсь, что этот сайт может сохранить мой пароль куда-то у себя перед тем, как полезет логинится с этим адресом и паролем по API.
Именно поэтому у большинства OAuth сервисов не включен Password Grant и в API нет никакого адреса входа по паролю. Возможен только вход через оригинальную форму по редиректу. Чтобы программисты других сайтов или приложений не делали свои формы-посредники.
Simon
2023-02-08 03:40
спасибо
Спасибо!