Нет, не класс.
При чём тут класс в пыхе, а если мне в очередь кладёт сообщения какой нибудь руби или java
Потому что у сообщения нет типа
Павел
Михаил
Есть
Павел
Это тупой стринг, поэтому я не пойму что за тип
Михаил
Давай без блейма. Если вы не знаете как решить мою проблему - не засоряйте чат
Павел
Давай без блейма. Если вы не знаете как решить мою проблему - не засоряйте чат
так мы уже выше общались, я предложил даже несколько вариантов))) Просто HandlersLocator заинтересовал. Ок расходимся
Мария
Всем привет! У нас в Санкт-Петербурге будет очередной митап про php. Можно сюда анонс запостить?
saber1in
Можете помочь с реализацией задачи.
У меня будет несколько отдельных докер контейнеров которые работают на разных портах.
Допустим у меня есть сервис облачного хранилища на диске сервера, а также есть другие подобные сервисы по разным нуждам
К некоторым таким сервисам я хочу иметь авторизацию, чтобы перед тем как пользоваться сервис проверить пользователя на авторизацию и на доступ к данному сервису.
Как можно это реализовать?
saber1in
Мне предложили использовать обратный прокси. Все запросы будут проходить через один nginx proxy, к сервисам которым нужна авторизация сначала запрос будет проксирован туда, и после уже к сервису.
saber1in
saber1in
saber1in
Хорошая ли эта идея, или есть более лучшие решения?
saber1in
Есть еще моменты, где внутри сервисов я хочу получать информацию о пользователе, с фронта у меня будет уникальный сеанс а внутри сервера как понять какой пользователь
Михаил
Да, идея хорошая.
Обычно такое делают через gateway. Запрос сначала приходит на gateway который единственный торчит наружу. Сервисы же скрыты внутри.
Гейтвей проводит аутентификацию(допустим по jwt токену) и пропускает запрос дальше или отшибает если токен не верен
Михаил
Авторизацией я бы всё таки дал рулить каждому сервису по отдельности, так как пользователь может быть внутри аутентификационного контура, но внутри каждого сервиса у него могут быть разные права и на некоторые действия он не авторизован
saber1in
Есть еще моменты, где внутри сервисов я хочу получать информацию о пользователе, с фронта у меня будет уникальный сеанс а внутри сервера как понять какой пользователь
Можно jwt токены использовать для этого, но я использую сессии и если даже буду юзать их, то это будет httponly чтобы фронт никак не знал о токене
saber1in
Авторизацией я бы всё таки дал рулить каждому сервису по отдельности, так как пользователь может быть внутри аутентификационного контура, но внутри каждого сервиса у него могут быть разные права и на некоторые действия он не авторизован
Чтобы пользовать одним сервисом каждый раз свою отдельную авторизацию проходить?
Михаил
Gateway может и по сессии проводить аутентификацию, без проблем. Просто jwt не требует дополнительных запросов.
Михаил
Чтобы пользовать одним сервисом каждый раз свою отдельную авторизацию проходить?
Авторизацию не нужно проходить. Она либо есть либо нет
saber1in
А как из сервисов получить информацию о пользователе?
saber1in
С сервиса авторизации
saber1in
С фронта это будет уникальная сессия, а внутри сервера её контекста же не будет
saber1in
Этот момент можно решать через токены, и обращаться с самих сервисов на локальный эндпоинт сервиса авторизации и так получить передав токены
Михаил
Или так или гейтвей может подшивать нужные данные.
Каждый сервис может ещё слушать очередь в кафке и если меняются данные пользователя - подхватывать их в локальную таблицу
Михаил
Рекомендую всё таки вести локальную таблицу, даже если вы запрашиваете по http
У информации есть свойство актуальности. Если данные могут быть неактуальными 10 минут, то в пределах этого времени вы можете не запрашивать по http а брать из бд или кеша
saber1in
Не совсем понимаю зачем дублировать данные пользователя с бд. Я не работал с кафкой, но сейчас имею представление что кафка работает как redis, чтобы просто хранить данные
saber1in
Понимаю что они отличаются и это связано с очередью, но сейчас такое поверхностное понимание, и поэтому не совсем понял предложенное решение
Михаил
Да она не совсем как редис. Она действительно kkv хранилище, но только хранит внутри себя лог
Михаил
Не важно, играйте тем, что вам раздали
Михаил
Сессии и http
Юра
Редис это инмемори дата сруктуры и алгоритмы
saber1in
В случае сессии как понимать какой это пользовать ведь у меня нет доступа из сервиса к сессии клиента
Юра
С возможностью песриста на диск как бонус
Михаил
Но всё таки советую присмотреться к jwt. Внутри него можно хранить не слишком секьюрные данные
saber1in
Но всё таки советую присмотреться к jwt. Внутри него можно хранить не слишком секьюрные данные
Да ей можно решить эти данные, просто даже интересно как можно это обыграть
saber1in
Если через сессии
Михаил
В случае сессии как понимать какой это пользовать ведь у меня нет доступа из сервиса к сессии клиента
Gateway может хранить связке сессия => id пользователя.
А дальше, когда он форвардит запрос он сможет передать заголовок с его id
Михаил
То есть gateway занимается тем что обменивает сессию на id пользака
saber1in
И эти данные предлагаете хранить в red is?
Михаил
Но если каждый сервис долбится в сервис с пользователим это ооооочень сильно увеличивает связанность
saber1in
Если я внутри самого gateway установлю заголовок то на сервис она же передасться?
Юра
Я как-то делал авторизацию через сертификат, отлично работает
Юра
Нгинкс валидирует и передает на бек метаданные сертификата
Михаил
Если я внутри самого gateway установлю заголовок то на сервис она же передасться?
Как сделаешь так и будет
Михаил
Зачем остальным сервисам знать что-то кроме id пользователя?
Михаил
1) запрос приходит на gateway
2) gateway из редиса достаёт сессию пользователя получает его роль и id
3) если сессии нет или роль не admin то это не авторизованный доступ - отшибаем с 401
4) если сессия есть и всё ок, перенаправляем запрос на нужный сервис с id пользователя
5) когда запрос приходит на сервис если нам нужно провести его авторизацию - мы просто локально заглядываем в таблицу где есть id пользака и список действий на которые он авторизован
6) если то действие которое он хочет совершить не совпадает с теми действиями что есть в таблице - 401
7) иначе совершаем это действие
saber1in
Мне нужен только I'd, сами данные я не буду передавать, если нужно будет эндпоинт у сервиса авторизации по получению данных пользователя
Михаил
Ну передавать с фронта что-то такое себе ну ладно
Михаил
1) запрос приходит на gateway
2) gateway из редиса достаёт сессию пользователя получает его роль и id
3) если сессии нет или роль не admin то это не авторизованный доступ - отшибаем с 401
4) если сессия есть и всё ок, перенаправляем запрос на нужный сервис с id пользователя
5) когда запрос приходит на сервис если нам нужно провести его авторизацию - мы просто локально заглядываем в таблицу где есть id пользака и список действий на которые он авторизован
6) если то действие которое он хочет совершить не совпадает с теми действиями что есть в таблице - 401
7) иначе совершаем это действие
а если у нас jwt то во время пункта 2) вообще не надо лезть в редис
saber1in
Мне нужен только I'd, сами данные я не буду передавать, если нужно будет эндпоинт у сервиса авторизации по получению данных пользователя
Всмысле тут нет фронта. В данном контексте сообщения
Михаил
Ааа
saber1in
Это будет общение между сервисасм внутри сервера
Михаил
, не правильно понял
saber1in
Если я внутри самого gateway установлю заголовок то на сервис она же передасться?
Поэтому был такой вопрос
Михаил
Ну тут другое дело.
это высокая связанность
вот у тебя 10 сервисов и 5 из них нужно запрашивать данные у сервиса авторизации. Такое себе.
Это и нагрузка и хрупкость
Михаил
Поэтому от размера проекта я бы всё таки задумался над сменой траспорта.
Какфка поможет инвертировать зависимость сервисов, сгладить нагрузку, не быть зависимым от поломок каждого сервиса (но конечно быть зависимым от кафки)
Ну а если проект маленький, то почему не монолит?)
saber1in
Просто хочу попробовать сделать такое, купил книжку DDD изучаю
Михаил
Да, я тоже когда Clean Code купил - решил всё нафиг переписать.
saber1in
Тоже самое, но у меня просто свой проектик не по работе
Михаил
а ну тогда вцелом метод проб и ошибок самое то.
Начни с одного, потом меняй в другую сторону.
Только личные проектики не дадут ту нагрузку что реальные проекты. Но по крайней мере могут дать представления о удобстве поддержки
Михаил
Вот хороший сайт про паттерны в MSA
https://microservices.io/articles/index.html
Оглавление справа снизу
saber1in
Юра
В любых делах связаныэ с секьюрити я сначала спрашиваю понимает ли человек разницу между авторизацией и аутентификацией
saber1in
Авторизация проверка на доступ, а аутентификация это вроде непосредственно проврека кредов
saber1in
Это так с ходу ответ
Юра
Ну вот раздели это дело
Юра
На уровне своих сервисов
saber1in
Ответ верный?
Юра
Аутентификация отвечает на вопрос кто? Авторизация на вопрос - что этот кто может сделать
Иван
Аутентификация отвечает на вопрос кто? Авторизация на вопрос - что этот кто может сделать
Аутентификация - вы, блядь, кто?
Авторизация - что вы, блядь, себе позволяете?
Роутинг - куда вы, блядь, лезете?
Валидация - что вы, блядь, несёте?
Юра
Блин за маты предупреждение но за шутку лайк
Юра
Получается что разрабы как старые бабки только в коде
Михаил
Михаил
Но мнемоника хорошая )
Павел
Мне нужен только I'd, сами данные я не буду передавать, если нужно будет эндпоинт у сервиса авторизации по получению данных пользователя
- Как вариант может вообще не быть единого сервиса авторизации. Идеальный микросервис/модуль - самодостаточный. Для этого он должен иметь все- данные у себя. Для этого он является либо его хозяином, либо дублирует. Но возможно ему вообще они не нужны.
- Исходя из предыдущего, что сервис должен иметь все данные, но вариант противоположенный, авторизитор единый и наоборот всё хранит в себе. Например кто автор статьи он хранит у себя, а не сервис статей. Потому что по большей части статьям нафиг не уперся кто там автор. Но это уже посложнее и требует большего анализа.
- Данные о пользователе != авторизация. Не надо путать авторизатор, с каким нить профилем или штукой которая хранит всё про юзер. Это к попрошу у сервиса авторизации данные пользователя
Ну и много зависит от задач и перфоманса + структуры. Те же накладки по http могут свое сыграть и надо это как то уменьшать. Одно дело что у вас ролевая модель, и авторизатор проверил роль по урлу, с этим легко справится гейтвей. А другое дело, что надо проверить что это такая то роль, является такой то ролью, это именно его ресурс для редактирования, и с момента создания ресурса должно пройти не менее 5 минут, если у него менее 100 статей, до 10 минут, если у него 500 статей, и бесконечно если у него купленны статус)))
В общем как обычно нет серебрянной пули