Страница входа и 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 для очистки старых кодов и токенов.

Скрытый контент
Комментарии (16)
Руслан

Спасибо!

Ответить
Максим

Спасибо!)

Ответить
v

Почему Fetcher из FindIdByCreedintials сам строит запрос в базу данных, а не обращается к UserRepository?

Ответить
Дмитрий Елисеев

Как раз об этом рассказал с 49-ой минуты

Ответить
Александр

Спасибо!

Ответить
fedot

Спасибо!

Ответить
Arunas

Спасибо :)

Ответить
Артем Астапов

Дмитрий, добавляйте пожалуйста ссылки на гайды - например, с сайта developer.okta.com и oauth2.thephpleague.com

Ответить
slo_nik

Добрый вечер, Дмитрий.

Подскажите, пожалуйста, если не использовать docker swarm, можно ли как-то прочитать файлы ключей в контейнере?

Пробовал в docker-compose.yml указать файлы ключей через secrets, но на рабочем сервере не получается прочитать файлы, отказано в доступе.

Права на файлы получаются 0400 и создаются от root.

Я пробовал указать mode в docker-compose.yml, но права на файл не менялись.

secrets:
        - source: db_password
          target: database_password_secret
          mode: 0440
Ответить
Дмитрий Елисеев

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

Ответить
slo_nik

Да, локально без проблем.

Проблемы на рабочем сервере.

Использование mode не помогло, поискал информацию в инете, но нашёл только то, что эти настройки работают только со swarm-ом, это как бы не полноценная настройка(возможно не так выразился). То есть, как бы я не менял права доступа к файлу через mode, права остаются без изменений.

Вот такими права остаются

-r-------- 1 slonik slonik   1273 мая 30 23:11 phpunit.xml.dist
Ответить
Ярослав

Когда я захожу по адресу 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. Может дело в нем?

Ответить
Ярослав

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

Ответить
Максим

Добрый день, и с наступающим новым годом! В данном уроке, Дмитрий, Вы используете чисты Sql. Получается что название таблиц и столбцов помимо маппинга на сущности ещё и будут в каждом таком запросе. Doctrine решает эту проблему с помощью Dql, плюс даёт возможность расширять этот язык. В своем проекте, я как раз пытаюсь уйти от нативного Sql, в пользу языка запросов к доменной модели.

Ответить
Максим

Здравствуйте. Столкнулся инфраструктурной проблемой и ридмоделями.

В объектах домена понятно дело нет всей информации для построения ридмодели.

К примеру нет понятия кем создана заявка - человеком/ботом. Кто владелец данной заявки, кто редактор.

Но нужна ли она бизнесу? Наверное нет, чем да. Но для построения рид модели понадобилась данная информация.

Как быть?

Единственное что я сейчас вижу это metadata у бизнес объектов куда я могу складировать дополнительную информацию. Создать какой-то отдельный контекст для этого и хранить всё там. Почему отдельный контекст? Потому что это не доменная модель. Бизнесу это не нужно в его контексте. Поэтому и портить доменную модель инфраструктурной частью приложения не хочется. Тогда где же хранить подобную информацию?

Ещё есть кейс - Owner. Когда есть владелец, чего-то и на основании этого надо предоставлять права на редактировании. Опять же это не бизнес требование, а предоставление доступа на уровне приложения. Соотвественно опять не хочется портить бизнес слой контекста. Тогда где хранить?

Хотелось бы услышать Ваши мысли. Благодарю!

Ответить
Дмитрий Елисеев

Проще всего хранить прямо в заявке.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu