Здравствуйте, Sinclair, Вы писали:

КЛ>>и как и откуда в эту схему кладутся данные?
S>Маппером, который сгенерирован по типу данных. Кладутся из DTO, который поднят из базы.

то есть пермисии определяются декларативно просто наличием полей в типе? ну-ну

КЛ>>я, кажется, начинаю понимать — по dto на роль, ORM, отдельные endpoints и вуаля?
S>Конечно.

вау

КЛ>>но тут есть 2 проблемы — работает только на простых security моделях,
S>Модели безопасности и должны быть простыми. Сложные модели снижают надёжность. Парадокс в том, что когда стоимость ошибки в секурити низкая, на неё можно просто забить. А когда высокая, то сложные модели слишком рискованны.

"хорошо это когда хорошо".

КЛ>>и никак не решает проблем, когда внутри этого dto есть многокардинальные поля (массивы etc, которые тоже надо фильтровать по роли).
S>Их не надо фильтровать по роли. Это плохая идея — слишком легко напороть.

тогда _какую_ проблему решают твои виртуальные ресурсы? никакую

КЛ>>ну есть еще конечно другой вариант — когда очень много денег и очень много ответственности и надо прям все по-красоте. но это не индустриальный стандарт
S>Да, я и говорю про серьёзные приложения, где ответственности много. А если её мало, то примерно любая секурити подойдёт.

серьезные приложения это софт для АЭС, там можно. В 99 процентах других случаев твоя модель не работает, такая моя оценка

КЛ>>я вообще про микросервисы ничего не писал, я утверждаю, что ты делаешь ту же самую работу по проверке пермиссий для резалтсета, только криво, а мы прямо)
S>Ну, с моей точки зрения криво делаете вы.
S>Получившимся API совершенно невозможно пользоваться, кроме как напрямую выкладывать его в ГУЙ. Любой сервис, который пытается стать клиентом этого API, вынужден жить в постоянной готовности получить не данные, а фигу.

при чем здесь вообще апи, когда мы говорим про то, как делать секьюрити внутри?

S>И как-то осмысленно объяснять пользователю, что "у тебя, брат, нет пермиссии на атрибут 'НДС', сходи к админу, попроси, чтоб выдал".

Google Cloud так и делает если что

S>Ну, либо (что скорее всего) внезапно падать с internal error 500, потому что внутрях там NullReferenceException.

домыслы

S>Разобраться, что там стало первопричиной, потребует привлечения дорогостоящего саппорта. Так что в пет проджектах, где пользователей меньше, чем ролей и пермиссий вместе взятых — велком, можно и так. А для чего-то серьёзного, где нужна предсказуемость работы — увольте.

дорогостоящий саппорт? дороже разработки?

КЛ>>вот и начинается, часть пермиссий через средства субд, часть сбоку, чтд
S>Где это я предложил часть пермиссий через средства СУБД? Я вам привёл стандартный способ разделения доступа "построчно" без использования row-level security.

ваши роли в субд и есть часть пермиссий через субд

КЛ>>так у вас нет row-level permission же
S>Я вроде дал пошаговое описание того, как решается проблема отсутствия row-level permissions в RDBMS. Причём не как рекомендацию использовать эту схему, а как пример реализации "послойной" безопасности.

а что тогда надо использовать в твоем случае?

S>Точно такие же рецепты применяются и в сервисах.
S>То есть токен пользователя у нас роляет только во фронт-сервисе. Когда пользователь U запрашивает API сервиса A, а сервис A в рамках этого запроса стучится в сервис B, то никакие токены U в этот B не передаются. У U вообще нет никакого доступа до сервиса B. В этот сервис обращается A, под собственным токеном.
S>Поэтому идея "а давайте у нас инвойс будет содержать данные контрагента если у вызывающего пользователя есть пермиссия на этого контрагента" сразу идёт навзничь.
S>У вызываюшего пользователя нет никаких пермиссий на контрагента — господь упаси. А вот право видеть реквизиты получателя платежа по выставленному счёту у него есть в силу федерального закона.

даже не буду комментировать, причем тут несколько сервисов и их взаимодействие я не понимаю, это вне контекста нашего обсуждения

КЛ>>" SQL исполнялся в контексте безопасности конечного пользователя " — вот это вообще что такое?
S>Это когда мы заводим для пользователя №44487 виндовый аккаунт, даём этому аккаунту права на SQL базу с табличками forums, topics, replies, и marks, при логине на сайт создаём виндовую сессию, и все запросы в SQL Server выполняем через новое соединение под правами этого виндового аккаунта.

кто так вообще делает? выглядит как полная дичь если честно

КЛ>>>>селект учитывает пермиссии юзера, получение по токену, чтобы выбрать только нужные строки, поля. работает с любым сочетанием и количеством ролей и пермиссий.
S>>>Можете привести пример такого select? Я вроде понимаю, о чём вы пишете, но уверенности нет.

КЛ>>select * from rows r
КЛ>>join rows_perms p on r.id = p.r_id
КЛ>> where p.perm = 'row_read' and p.user_id = :userid
S>Прекрасно. Вы себе представляете производительность такого решения? Когда у нас табличка на пару миллионов строк, и есть тысяча пользователей с частично пересекающимися правами на эти строки?

да, индекс на rows_perms.user_id и будет быстро, плюс там еще в 99 процентах будет предикат на индексированное поле как часть фильтра поискового запроса. да, часто данные для всех лежать в одной таблице и когда нужен row-level security у тебя просто нет выбора. либо копии данных (твои views видимо) либо так.

но это на запрос коллекции, а на запрос одного ресурса вообще все быстро потому что индекс и на rows_perms.id

select * from rows r
join rows_perms p on r.id = p.r_id
where p.perm = 'row_read' and p.user_id = :userid and r.id = :id

КЛ>>или
КЛ>>select * from rows r where r.group_id in :user_groups
S>А как же "любое сочетание ролей и пермиссий"? Вы прибиваете доступ к r только к одной роли; невозможно выдать доступ к конкретной строке нескольким разным группам.
S>Собственно, вы изобретаете нормальную изоляцию на основе бизнес-правил, только задом наперёд.

ты просил примеры, я привел сложный и простой (для твоей модели где есть только роли)

S>Это — совершенно нормальная история, которая работает и применяется.
КЛ>>userid/user_groups резолвятся по токену из запроса
S>Ну, вы же только что собирались сделать универсальную схему, которая работает с любым количеством пермиссий и ролей. А получается вполне себе узкоспециализированная штука.

первый пример довольно универсален, он иллюстрирует подход "на основании токена фильтруем резалтсет и тп"

S>Непонятно. Как я смогу получить разный набор полей для разных строк одной и той же таблицы? Речь-то шла именно об этом — что состав результата определяется не объектом, а правами пользователя на него.

на чистом sql очевидно никак, для некоторых строк в резалтсете надо фильтровать поля (будут null), если ты об этом
а в твоем случае как? у тебя же схема прибита гвоздями

КЛ>>да, но ничего с точки зрения трейдоффа разработка/результат не придумали. открываешь google aim и видишь и роли, и отдельные пермиссии.
S>Надо внимательно смотреть на то, как именно используются эти роли и пермиссии. Потому что я так-то не против ролей и пермиссий; я против смешивания мух и котлет.
S>И если я запрашиваю, допустим, GET /resources/{resourceId}?$include(usageHistory), а у меня нет пермиссий смотреть usageHistory по этому ресурсу, я получаю не пустую историю и не JSON с "вырезанным" атрибутом, а честный 403. А если у меня пермиссия есть, то я могу полагаться на то, что в результате будет атрибут usageHistory с описанной в схеме структурой.

как тут помогают роутеры?

S>В итоге сторонний сервис, который потребляет мой API, может выдавать осмысленные ошибки, которые можно быстро исправить. А не просто падать оттого, что его авторы тестировались с аккаунтом, у которого были все нужные пермиссии, и понятия не имели, что у кого-то пермиссия на usageHistory на какой-то отдельный объект может быть отобрана.

да ну я тебе сделаю отдельный endpoint, но внутри будет один движок по доставке данных, который может тебе отдавать 403 в когда надо

S>Обратите внимание — это то самое "разведение ресурсов по разным URL", над которым вы так потешались.

мы потешаемся не над ним, а над тем, что ты полагаешься только на него

КЛ>>много ролей, много разных пермиссий
S>Количество ни на что не влияет.

на комбинаторный взрыв сущностей

КЛ>>ага, то есть любой смоук тест у нас в лобой системе обнаруживает любую проблему?
S>Нет, только детерминистические вещи.

это что? каков критерий?

КЛ>>и никто ее не делает, потому что это невозможно поддерживать
S> Надо просто уметь это готовить.


сколько раз мы уже это слышали по поводу всего. похоже на отмазку для неадекватного задаче решения