Комментарии 8
А как лучше сделать то что вы предлагаете для авторизации per контент(допустим как куплена или нет статья) или per creator (допустим куплена подписка на человека с доступом ко всем статьям).
Неужто перед каждым запросом лезть в базу и чекать в биллинге и других проемов нету ?
В контексте статьи я бы подумал в первую очередь как нести эту информацию в токене - создатель, купил доступ и т.п.
Только надо обязательно учитывать, что жирные токены приведут к потере перфоманса. Тут надо искать баланс.
Есть ещё один вариант - это подумать как сделать PIP - https://www.axiomatics.com/policy-information-point-in-five-minutes/
Интересная реализация. Спасибо!
Выглядит более чем привлекательно, ведь если заводить все ресурсы в keycloak и там же вести scope`ы доступа к ним, настроить группы и работать по jwt, на первый взгляд и правда кажется что можно не париться об этом в приложении.
Но сдаётся мне что приложение всё равно должно будет сверяться с тем же keycloak в различных выборках. Тем не менее, выглядит любопытно)
Пробовал я как-то авторизацию со всеми authorization/scope и прочими плюшками из кейклока. Гибкая штука, но перфоманс у неё отвратительный. И когда я искал инфу как сделать побыстрее наткнулся на обсуждение в группе кейклока, где авторы сказали - нам надо было сделать гибко, а не быстро. Хотите скорости - делайте кэш.
Это то что мне было нужно, и тут вы! Браво!
Публикации
Авторизация для бедных или как сделать RBAC для REST API с помощью OPA