Петр,
JWT может содержать что угодно, лишь бы не дергать сервис авторизации лишний раз (зачем его дергать, если в токене будет всё? Минус одна зависимость в пайлайне обработки запроса)
У нас в токене есть список пермишенов (пусть для просмотра транзакции у нас пермишн trans_view), список групп и подразделений к которым пользователь имеет доступ.
Впрочем не суть, в токене хранятся эти данные или gateway на каждый запрос лазит в сервис авторизации.
Gateway проверяет, что в токене есть пермишн trans_view, а дальше что? Как ограничить доступ к конкретной транзакции по принадлежности к группе и подразделению?
Петр,
"Gateway проверяет права доступа к данным."
Вот тут я логику немного не понимаю. Есть две ситуации:
1. Пользователь запрашивает последние 30 транзакций. Сервис транзакций отдает список, фильтранув его по доступным группам/подразделениям. Если фильтрацию отдать на сторону Gateway, то получим не 30 записей, а меньше. Следовательно сервис транзакций так или иначе должен обрабатывать содержимое JWT-токена или сходить в сервис авторизации и запросить что этому пользователю позволено.
2. Пользователь запрашивает транзакию с id=7152522. Откуда сервис gateway узнает можно ли этому пользователю получить данные по этой транзакции? Только запросив сервис транзакций. Т.е. запрос в любом случае уйдет в сервис транзакций и будет запрос в БД. Так сервис транзакций у нас уже обрабатывает JWT токен (чтобы корректно работать для ситуации 1), а значит права доступа можно проверить в самом сервисе транзакций.
Зачем тут gateway?
Использование Gateway в качестве "объединятора" данных с разных сервисов в один ответ мне кажется вообще антипаттерном.
Т.е. у нас условно идет запрос по данным транзакции, ее надо обогатить сторонними данными типа ФИО, это значит надо будет еще дернуть сервис пользователей. А если таких сторонних поставщиков много - то ради одного запроса напрягаем 100500 сервисов. Ну такое.
У нас вообще gateway нет. Был, но убрали, т.к. смысла в нем отсутствует, только усложняет разработку и развертывание.
Проверять роли? Каждый сервис у нас и так проверяет роли, т.к. у нас не только по ролям ограничения, но еще и по подразделениям и группам. Кто лучше сервиса транзакций знает к какой группе и подразделению относится конкретная транзакция? Никто. Соответственно ему и проверять доступ.
Объединять несколько запросов в один? Смысл? Фронту проще сделать несколько запросов. Про обогащение уже писал.
Петр, Если нам нужно искать по транзакциям (например фильтрануть по дате, по сумме, по пользователю), то как иначе? В каком-то, возможно урезанном виде, но придется тащить эти транзакции в сервис поиска.
Плюс это не решает вопрос подробного отображения данных по транзакции (а там свыше 20 полей, 5 из которых - id на справочники - это тоже все тащить в сервис поиска?).
Я так не заморачивался, у меня сервис транзакций одновременно выступает и сервисом поиска. Благо никакого хитрого поиска с морфологией бизнесу не нужно (Elastik не нужОн) и постгресс вполне справляется.
Я же ищу варианты как не дублировать данные в принципе, или минимизировать это.
Но судя по всему никак.
Ну в целом все тоже самое, только у вас еще и сервис поиска (зачем?), в котором кроме списка пользователей, видимо, еще придется продублировать и список транзакций.
В сервисе транзакций продублирован список пользователей (как минимум id), а значит сервису при первом старте все-равно надо получить все миллионы записей.
В сервисе поиска надо не только миллионы пользователей продублировать, но еще и сотни миллионов транзакций.
Т.е. подход не решает основную проблему дублирования данных (что в целом вроде как и не проблема), так же не решает проблему долгой начальной синхронизации (это вроде тоже не проблема, но хочется лучше)
ThunderCat, конечно же пробовал
CREATE TABLE `test` (
`client_id` int(11) NOT NULL,
`period` date NOT NULL DEFAULT (curdate())
);
ALTER TABLE `test` CHANGE `client_id` `client_id` int(11) NOT NULL COMMENT 'Клиент';
Выдает ошибку.
Самое интересное, если у колонки period убрать NOT NULL, то все работает! Ошибок не выдает
ThunderCat, Ну вот так работает yii2, сначала создает таблицу, а потом добавляет комментарии.
Но сам факт, что с такой таблицей потом ничего не сделать - это проблема.
С 8.0.13 можно использовать выражения, как написано в доке: https://dev.mysql.com/doc/refman/8.0/en/data-type-...
The default value specified in a DEFAULT clause can be a literal constant or an expression. With one exception, enclose expression default values within parentheses to distinguish them from literal constant default values.
И там же пример с колонкой типа date.
А CURRENT_TIMESTAMP не работает с колонкой типа date. Ругается на несовместимость типов.
Таблица создается. Как в варианте
`period` date NOT NULL DEFAULT (CURRENT_DATE),
так и в варианте
`period` date NOT NULL DEFAULT (curdate()),
Причем независимо от способа создания таблицы show create table покажет `period` date NOT NULL DEFAULT (curdate())
Но вот дальше любой alter table client_balance .... выдает ERROR 1067 (42000): Invalid default value for 'period'
ALTER TABLE `client_balance` CHANGE `client_id` `client_id` int(11) NOT NULL COMMENT 'Клиент';
ERROR 1067 (42000): Invalid default value for 'period'
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
JWT может содержать что угодно, лишь бы не дергать сервис авторизации лишний раз (зачем его дергать, если в токене будет всё? Минус одна зависимость в пайлайне обработки запроса)
У нас в токене есть список пермишенов (пусть для просмотра транзакции у нас пермишн trans_view), список групп и подразделений к которым пользователь имеет доступ.
Впрочем не суть, в токене хранятся эти данные или gateway на каждый запрос лазит в сервис авторизации.
Gateway проверяет, что в токене есть пермишн trans_view, а дальше что? Как ограничить доступ к конкретной транзакции по принадлежности к группе и подразделению?