Сообщение Re[27]: Каких программ вам не хватает? от 17.04.2025 15:07
Изменено 17.04.2025 15:24 Кt Л.
Re[27]: Каких программ вам не хватает?
Здравствуйте, Sinclair, Вы писали:
КЛ>>кто его оттуда вырезал?
S>Я не понимаю термина "вырезал". Никто никого ниоткуда не "вырезал".
S>Просто у нас есть такой тип данных, InboundInvoice, который отличается от OutboundInvoice.
S>На стороне сервиса они могут находиться в каких-то взаимоотношениях друг с другом (типа — оба отнаследованы от общей базы, или собираются путём алгебры типов из запчастей, вроде CommonInvoice & InboundInvoice / CommonInvoice & OutboundInvoice).
S>Снаружи мы всё равно видим только схему Json, и она разная для разных ендпоинтов.
и как и откуда в эту схему кладутся данные?
КЛ>>ты тут смешиваешь свои и чужие инвойсы, чтобы навести туману.
S>Это не я смешиваю
КЛ>>давай мы будем всегда про свои инвойсы, но в одном случае для отчетности, в другом для превью — как хранить будешь и разделять?
S>Я не буду их разделять — зачем? Мне непонятен сценарий. Если дадите больше деталей — можно спроектировать.
КЛ>>он так не предлагает
мне кажется он специально преувеличил, но не суть
S>Цитирую:
S>
КЛ>>ну то есть делает именно то, что мы тут тебе и говорим
S>Нет, делает ровно противоположное. Более того, прямо тут в топике приводились утверждения про то, что "на самом деле" микросервисы не только пользовательских принципалов не используют, а вообще бегают все под одним и тем же аккаунтом.
я вообще про микросервисы ничего не писал, я утверждаю, что ты делаешь ту же самую работу по проверке пермиссий для резалтсета, только криво, а мы прямо)
КЛ>>почему это мы не можем?
S>Потому что row level security есть далеко не в любой СУБД. И даже в тех, где такое есть, далеко не всегда это будет наиболее эффективным решением.
вот и начинается, часть пермиссий через средства субд, часть сбоку, чтд
КЛ>>зачем? только столбцы выбросить?
S>И строки тоже.
так у вас нет row-level permission же
КЛ>>такое работает только когда у тебя 2-3 роли в аппке и мало пермиссий
S>Такое работает примерно всегда. Я ещё ни разу не видел настолько безумной архитектуры, чтобы SQL исполнялся в контексте безопасности конечного пользователя, пришедшего из интернета.
" SQL исполнялся в контексте безопасности конечного пользователя " — вот это вообще что такое? что тут ты понимаешь под контекстом? а когда ты делаешь эти свои лишние телодвижения из 3х пунктов, ты разве не мапишь "контексте безопасности конечного пользователя, пришедшего из интернета" на конкретную роль в базе?
sql исполняется от админа всегда и точка. резалсеты зависят от пермиссий юзера из интернета.
КЛ>>это все не надо. у каждой строки есть поле, по которому мы понимаем какая пермиссия нужна, чтобы его читать.
S>"Его" — это кого? Поле?
строку, опечатка конечно
КЛ>>селект учитывает пермиссии юзера, получение по токену, чтобы выбрать только нужные строки, поля. работает с любым сочетанием и количеством ролей и пермиссий.
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
или
select * from rows r where r.group_id in :user_groups
userid/user_groups резолвятся по токену из запроса
да как угодно, при том, что работает тот самый швейцарский сыр, про который тут упоминали —
возможность вообще что-то читать из таблицы rows проверяется до отправки sql в базу. все запросы от админа. в базе никакой встроенной security не используется, потому что, опять же, нет нормально row-level security встроенного. С полями — либо динамически генеришь строку sql, либо jooq (предпочтительнее)
select fields from field_perm where field_perm.perm = 'row_read_for_report'
и дальше ипользуешь результат для генерации верхних селектов с конкретными полями.
либо уже просто в коде фильтруешь
КЛ>>а ведь еще ничего не сказано про ABAC, который часто нужен и который в твою схему вообще не вписывается
S>Да, для ABAC нужна другая схема. Но он очень часто является оверкиллом.
ABAC, это когда ты принимаешь решение не только от роли, но и контекста — времени запроса и пт. То есть довольно часто.
КЛ>>действительно, результат поискового запроса зависит от критериев поиска (пермиссии один из них внезапно), вот это дичь, да?
S>Отож. Не, я всё это умею делать. Но в эксплуатации такие "гибкие схемы" гораздо чаще приносят вред, чем пользу.
S>Вот, в прошлом году в одной крупной компании был случай, когда из-за цепочки нечаянных совпадений и недопониманий друг друга, одному из сотрудников выдали чутка больше "пермиссий", чем надо было по его роли.
S>В итоге сотрудник из лучших побуждений наворотил делов. Хорошо, что речь шла о добронамеренном сотруднике, поэтому последствия были не очень тяжкими (ну, там, зарплату задержали на пару дней части сотрудников). А в иной ситуации это бы вышло таким боком, что никакая экономия на архитектуре не окупилась бы.
да, но ничего с точки зрения трейдоффа разработка/результат не придумали. открываешь google aim и видишь и роли, и отдельные пермиссии.
КЛ>>для петпроджектов да, но мы о нормальных системах говорим
S>Ну, критерии "нормальных систем" у всех разные.
много ролей, много разных пермиссий
КЛ>>а если ты внутри роутинга не туда нароутил?
S>То это будет обнаружено первым же smoke test.
ага, то есть любой смоук тест у нас в лобой системе обнаруживает любую проблему?
КЛ>>ну это звучит как "доказать, что код выдает правильную поисковую выдачу та еще задача".
S>Конечно. Это вполне актуальная проблема; и основное её решение ровно то же, что я предлагаю — факторизация. Потому что иначе вы точно так же утонете в объёме тестирования.
и никто ее не делает, потому что это невозможно поддерживать
КЛ>>кто его оттуда вырезал?
S>Я не понимаю термина "вырезал". Никто никого ниоткуда не "вырезал".
S>Просто у нас есть такой тип данных, InboundInvoice, который отличается от OutboundInvoice.
S>На стороне сервиса они могут находиться в каких-то взаимоотношениях друг с другом (типа — оба отнаследованы от общей базы, или собираются путём алгебры типов из запчастей, вроде CommonInvoice & InboundInvoice / CommonInvoice & OutboundInvoice).
S>Снаружи мы всё равно видим только схему Json, и она разная для разных ендпоинтов.
и как и откуда в эту схему кладутся данные?
КЛ>>ты тут смешиваешь свои и чужие инвойсы, чтобы навести туману.
S>Это не я смешиваю
КЛ>>давай мы будем всегда про свои инвойсы, но в одном случае для отчетности, в другом для превью — как хранить будешь и разделять?
S>Я не буду их разделять — зачем? Мне непонятен сценарий. Если дадите больше деталей — можно спроектировать.
КЛ>>он так не предлагает
мне кажется он специально преувеличил, но не суть
S>Цитирую:
S>
S>А на самом деле json генерится питонячим кодом, который рефлексией вываливает всё что есть
КЛ>>ну то есть делает именно то, что мы тут тебе и говорим
S>Нет, делает ровно противоположное. Более того, прямо тут в топике приводились утверждения про то, что "на самом деле" микросервисы не только пользовательских принципалов не используют, а вообще бегают все под одним и тем же аккаунтом.
я вообще про микросервисы ничего не писал, я утверждаю, что ты делаешь ту же самую работу по проверке пермиссий для резалтсета, только криво, а мы прямо)
КЛ>>почему это мы не можем?
S>Потому что row level security есть далеко не в любой СУБД. И даже в тех, где такое есть, далеко не всегда это будет наиболее эффективным решением.
вот и начинается, часть пермиссий через средства субд, часть сбоку, чтд
КЛ>>зачем? только столбцы выбросить?
S>И строки тоже.
так у вас нет row-level permission же
КЛ>>такое работает только когда у тебя 2-3 роли в аппке и мало пермиссий
S>Такое работает примерно всегда. Я ещё ни разу не видел настолько безумной архитектуры, чтобы SQL исполнялся в контексте безопасности конечного пользователя, пришедшего из интернета.
" SQL исполнялся в контексте безопасности конечного пользователя " — вот это вообще что такое? что тут ты понимаешь под контекстом? а когда ты делаешь эти свои лишние телодвижения из 3х пунктов, ты разве не мапишь "контексте безопасности конечного пользователя, пришедшего из интернета" на конкретную роль в базе?
sql исполняется от админа всегда и точка. резалсеты зависят от пермиссий юзера из интернета.
КЛ>>это все не надо. у каждой строки есть поле, по которому мы понимаем какая пермиссия нужна, чтобы его читать.
S>"Его" — это кого? Поле?
строку, опечатка конечно
КЛ>>селект учитывает пермиссии юзера, получение по токену, чтобы выбрать только нужные строки, поля. работает с любым сочетанием и количеством ролей и пермиссий.
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
или
select * from rows r where r.group_id in :user_groups
userid/user_groups резолвятся по токену из запроса
да как угодно, при том, что работает тот самый швейцарский сыр, про который тут упоминали —
возможность вообще что-то читать из таблицы rows проверяется до отправки sql в базу. все запросы от админа. в базе никакой встроенной security не используется, потому что, опять же, нет нормально row-level security встроенного. С полями — либо динамически генеришь строку sql, либо jooq (предпочтительнее)
select fields from field_perm where field_perm.perm = 'row_read_for_report'
и дальше ипользуешь результат для генерации верхних селектов с конкретными полями.
либо уже просто в коде фильтруешь
КЛ>>а ведь еще ничего не сказано про ABAC, который часто нужен и который в твою схему вообще не вписывается
S>Да, для ABAC нужна другая схема. Но он очень часто является оверкиллом.
ABAC, это когда ты принимаешь решение не только от роли, но и контекста — времени запроса и пт. То есть довольно часто.
КЛ>>действительно, результат поискового запроса зависит от критериев поиска (пермиссии один из них внезапно), вот это дичь, да?
S>Отож. Не, я всё это умею делать. Но в эксплуатации такие "гибкие схемы" гораздо чаще приносят вред, чем пользу.
S>Вот, в прошлом году в одной крупной компании был случай, когда из-за цепочки нечаянных совпадений и недопониманий друг друга, одному из сотрудников выдали чутка больше "пермиссий", чем надо было по его роли.
S>В итоге сотрудник из лучших побуждений наворотил делов. Хорошо, что речь шла о добронамеренном сотруднике, поэтому последствия были не очень тяжкими (ну, там, зарплату задержали на пару дней части сотрудников). А в иной ситуации это бы вышло таким боком, что никакая экономия на архитектуре не окупилась бы.
да, но ничего с точки зрения трейдоффа разработка/результат не придумали. открываешь google aim и видишь и роли, и отдельные пермиссии.
КЛ>>для петпроджектов да, но мы о нормальных системах говорим
S>Ну, критерии "нормальных систем" у всех разные.
много ролей, много разных пермиссий
КЛ>>а если ты внутри роутинга не туда нароутил?
S>То это будет обнаружено первым же smoke test.
ага, то есть любой смоук тест у нас в лобой системе обнаруживает любую проблему?
КЛ>>ну это звучит как "доказать, что код выдает правильную поисковую выдачу та еще задача".
S>Конечно. Это вполне актуальная проблема; и основное её решение ровно то же, что я предлагаю — факторизация. Потому что иначе вы точно так же утонете в объёме тестирования.
и никто ее не делает, потому что это невозможно поддерживать
Re[27]: Каких программ вам не хватает?
Здравствуйте, Sinclair, Вы писали:
S>Снаружи мы всё равно видим только схему Json, и она разная для разных ендпоинтов.
и как и откуда в эту схему кладутся данные?
я, кажется, начинаю понимать — по dto на роль, ORM, отдельные endpoints и вуаля? но тут есть 2 проблемы — работает только на простых security моделях, и никак не решает проблем, когда внутри этого dto есть многокардинальные поля (массивы etc, которые тоже надо фильтровать по роли).
ну есть еще конечно другой вариант — когда очень много денег и очень много ответственности и надо прям все по-красоте. но это не индустриальный стандарт
КЛ>>ты тут смешиваешь свои и чужие инвойсы, чтобы навести туману.
S>Это не я смешиваю
КЛ>>давай мы будем всегда про свои инвойсы, но в одном случае для отчетности, в другом для превью — как хранить будешь и разделять?
S>Я не буду их разделять — зачем? Мне непонятен сценарий. Если дадите больше деталей — можно спроектировать.
КЛ>>он так не предлагает
мне кажется он специально преувеличил, но не суть
S>Цитирую:
S>
КЛ>>ну то есть делает именно то, что мы тут тебе и говорим
S>Нет, делает ровно противоположное. Более того, прямо тут в топике приводились утверждения про то, что "на самом деле" микросервисы не только пользовательских принципалов не используют, а вообще бегают все под одним и тем же аккаунтом.
я вообще про микросервисы ничего не писал, я утверждаю, что ты делаешь ту же самую работу по проверке пермиссий для резалтсета, только криво, а мы прямо)
КЛ>>почему это мы не можем?
S>Потому что row level security есть далеко не в любой СУБД. И даже в тех, где такое есть, далеко не всегда это будет наиболее эффективным решением.
вот и начинается, часть пермиссий через средства субд, часть сбоку, чтд
КЛ>>зачем? только столбцы выбросить?
S>И строки тоже.
так у вас нет row-level permission же
КЛ>>такое работает только когда у тебя 2-3 роли в аппке и мало пермиссий
S>Такое работает примерно всегда. Я ещё ни разу не видел настолько безумной архитектуры, чтобы SQL исполнялся в контексте безопасности конечного пользователя, пришедшего из интернета.
" SQL исполнялся в контексте безопасности конечного пользователя " — вот это вообще что такое? что тут ты понимаешь под контекстом? а когда ты делаешь эти свои лишние телодвижения из 3х пунктов, ты разве не мапишь "контексте безопасности конечного пользователя, пришедшего из интернета" на конкретную роль в базе?
sql исполняется от админа всегда и точка. резалсеты зависят от пермиссий юзера из интернета.
КЛ>>это все не надо. у каждой строки есть поле, по которому мы понимаем какая пермиссия нужна, чтобы его читать.
S>"Его" — это кого? Поле?
строку, опечатка конечно
КЛ>>селект учитывает пермиссии юзера, получение по токену, чтобы выбрать только нужные строки, поля. работает с любым сочетанием и количеством ролей и пермиссий.
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
или
select * from rows r where r.group_id in :user_groups
userid/user_groups резолвятся по токену из запроса
да как угодно, при том, что работает тот самый швейцарский сыр, про который тут упоминали —
возможность вообще что-то читать из таблицы rows проверяется до отправки sql в базу. все запросы от админа. в базе никакой встроенной security не используется, потому что, опять же, нет нормально row-level security встроенного. С полями — либо динамически генеришь строку sql, либо jooq (предпочтительнее)
select fields from field_perm where field_perm.perm = 'row_read_for_report'
и дальше ипользуешь результат для генерации верхних селектов с конкретными полями.
либо уже просто в коде фильтруешь
КЛ>>а ведь еще ничего не сказано про ABAC, который часто нужен и который в твою схему вообще не вписывается
S>Да, для ABAC нужна другая схема. Но он очень часто является оверкиллом.
ABAC, это когда ты принимаешь решение не только от роли, но и контекста — времени запроса и пт. То есть довольно часто.
КЛ>>действительно, результат поискового запроса зависит от критериев поиска (пермиссии один из них внезапно), вот это дичь, да?
S>Отож. Не, я всё это умею делать. Но в эксплуатации такие "гибкие схемы" гораздо чаще приносят вред, чем пользу.
S>Вот, в прошлом году в одной крупной компании был случай, когда из-за цепочки нечаянных совпадений и недопониманий друг друга, одному из сотрудников выдали чутка больше "пермиссий", чем надо было по его роли.
S>В итоге сотрудник из лучших побуждений наворотил делов. Хорошо, что речь шла о добронамеренном сотруднике, поэтому последствия были не очень тяжкими (ну, там, зарплату задержали на пару дней части сотрудников). А в иной ситуации это бы вышло таким боком, что никакая экономия на архитектуре не окупилась бы.
да, но ничего с точки зрения трейдоффа разработка/результат не придумали. открываешь google aim и видишь и роли, и отдельные пермиссии.
КЛ>>для петпроджектов да, но мы о нормальных системах говорим
S>Ну, критерии "нормальных систем" у всех разные.
много ролей, много разных пермиссий
КЛ>>а если ты внутри роутинга не туда нароутил?
S>То это будет обнаружено первым же smoke test.
ага, то есть любой смоук тест у нас в лобой системе обнаруживает любую проблему?
КЛ>>ну это звучит как "доказать, что код выдает правильную поисковую выдачу та еще задача".
S>Конечно. Это вполне актуальная проблема; и основное её решение ровно то же, что я предлагаю — факторизация. Потому что иначе вы точно так же утонете в объёме тестирования.
и никто ее не делает, потому что это невозможно поддерживать
S>Снаружи мы всё равно видим только схему Json, и она разная для разных ендпоинтов.
и как и откуда в эту схему кладутся данные?
я, кажется, начинаю понимать — по dto на роль, ORM, отдельные endpoints и вуаля? но тут есть 2 проблемы — работает только на простых security моделях, и никак не решает проблем, когда внутри этого dto есть многокардинальные поля (массивы etc, которые тоже надо фильтровать по роли).
ну есть еще конечно другой вариант — когда очень много денег и очень много ответственности и надо прям все по-красоте. но это не индустриальный стандарт
КЛ>>ты тут смешиваешь свои и чужие инвойсы, чтобы навести туману.
S>Это не я смешиваю
КЛ>>давай мы будем всегда про свои инвойсы, но в одном случае для отчетности, в другом для превью — как хранить будешь и разделять?
S>Я не буду их разделять — зачем? Мне непонятен сценарий. Если дадите больше деталей — можно спроектировать.
КЛ>>он так не предлагает
мне кажется он специально преувеличил, но не суть
S>Цитирую:
S>
S>А на самом деле json генерится питонячим кодом, который рефлексией вываливает всё что есть
КЛ>>ну то есть делает именно то, что мы тут тебе и говорим
S>Нет, делает ровно противоположное. Более того, прямо тут в топике приводились утверждения про то, что "на самом деле" микросервисы не только пользовательских принципалов не используют, а вообще бегают все под одним и тем же аккаунтом.
я вообще про микросервисы ничего не писал, я утверждаю, что ты делаешь ту же самую работу по проверке пермиссий для резалтсета, только криво, а мы прямо)
КЛ>>почему это мы не можем?
S>Потому что row level security есть далеко не в любой СУБД. И даже в тех, где такое есть, далеко не всегда это будет наиболее эффективным решением.
вот и начинается, часть пермиссий через средства субд, часть сбоку, чтд
КЛ>>зачем? только столбцы выбросить?
S>И строки тоже.
так у вас нет row-level permission же
КЛ>>такое работает только когда у тебя 2-3 роли в аппке и мало пермиссий
S>Такое работает примерно всегда. Я ещё ни разу не видел настолько безумной архитектуры, чтобы SQL исполнялся в контексте безопасности конечного пользователя, пришедшего из интернета.
" SQL исполнялся в контексте безопасности конечного пользователя " — вот это вообще что такое? что тут ты понимаешь под контекстом? а когда ты делаешь эти свои лишние телодвижения из 3х пунктов, ты разве не мапишь "контексте безопасности конечного пользователя, пришедшего из интернета" на конкретную роль в базе?
sql исполняется от админа всегда и точка. резалсеты зависят от пермиссий юзера из интернета.
КЛ>>это все не надо. у каждой строки есть поле, по которому мы понимаем какая пермиссия нужна, чтобы его читать.
S>"Его" — это кого? Поле?
строку, опечатка конечно
КЛ>>селект учитывает пермиссии юзера, получение по токену, чтобы выбрать только нужные строки, поля. работает с любым сочетанием и количеством ролей и пермиссий.
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
или
select * from rows r where r.group_id in :user_groups
userid/user_groups резолвятся по токену из запроса
да как угодно, при том, что работает тот самый швейцарский сыр, про который тут упоминали —
возможность вообще что-то читать из таблицы rows проверяется до отправки sql в базу. все запросы от админа. в базе никакой встроенной security не используется, потому что, опять же, нет нормально row-level security встроенного. С полями — либо динамически генеришь строку sql, либо jooq (предпочтительнее)
select fields from field_perm where field_perm.perm = 'row_read_for_report'
и дальше ипользуешь результат для генерации верхних селектов с конкретными полями.
либо уже просто в коде фильтруешь
КЛ>>а ведь еще ничего не сказано про ABAC, который часто нужен и который в твою схему вообще не вписывается
S>Да, для ABAC нужна другая схема. Но он очень часто является оверкиллом.
ABAC, это когда ты принимаешь решение не только от роли, но и контекста — времени запроса и пт. То есть довольно часто.
КЛ>>действительно, результат поискового запроса зависит от критериев поиска (пермиссии один из них внезапно), вот это дичь, да?
S>Отож. Не, я всё это умею делать. Но в эксплуатации такие "гибкие схемы" гораздо чаще приносят вред, чем пользу.
S>Вот, в прошлом году в одной крупной компании был случай, когда из-за цепочки нечаянных совпадений и недопониманий друг друга, одному из сотрудников выдали чутка больше "пермиссий", чем надо было по его роли.
S>В итоге сотрудник из лучших побуждений наворотил делов. Хорошо, что речь шла о добронамеренном сотруднике, поэтому последствия были не очень тяжкими (ну, там, зарплату задержали на пару дней части сотрудников). А в иной ситуации это бы вышло таким боком, что никакая экономия на архитектуре не окупилась бы.
да, но ничего с точки зрения трейдоффа разработка/результат не придумали. открываешь google aim и видишь и роли, и отдельные пермиссии.
КЛ>>для петпроджектов да, но мы о нормальных системах говорим
S>Ну, критерии "нормальных систем" у всех разные.
много ролей, много разных пермиссий
КЛ>>а если ты внутри роутинга не туда нароутил?
S>То это будет обнаружено первым же smoke test.
ага, то есть любой смоук тест у нас в лобой системе обнаруживает любую проблему?
КЛ>>ну это звучит как "доказать, что код выдает правильную поисковую выдачу та еще задача".
S>Конечно. Это вполне актуальная проблема; и основное её решение ровно то же, что я предлагаю — факторизация. Потому что иначе вы точно так же утонете в объёме тестирования.
и никто ее не делает, потому что это невозможно поддерживать