Pull to refresh

Comments 9

Дело в том, что в системе есть очень разумное требование, заключающееся в том, что если пользователь НЕ может читать документ по правам, то значит он вообще не должен знать о его существовании, а значит – результаты поисков объектов в системе должны фильтроваться на основании прав пользователя.

Жизнь гораздо более жестока… часто пользователь, не имеющий прав доступа к документу, должен не только знать что он есть, знать кто его может прочитать, но и иметь доступ к некоторым его данным.
А какие сценарии этого могут требовать? Если речь идёт о том, что непосредственно сам пользователь должен, не обладая правами, иметь возможность зачитать данные какого-то объекта — то это ведь дырка в безопасности.
А вот если речь идёт о прикладном коде, выполняющемся от имени пользователя — то да, такая штука бывает. Можно для этого реализовать отключение проверки прав внутри прикладного кода логики. Грубо говоря, пользователь инициирует операцию, на первом этапе проверяются права этого пользователя в плане возможности выполнить эту операцию, а затем прикладной код работает в «безопасном режиме», без проверки прав на другие объекты. Или можно завести системного пользователя, обладающего всеми правами и имперсонироваться в него в бизнес-логике, когда нужно.
Сценарий может быть такой: объект — документ, часть полей которого заполняет секретарь, а часть руководитель.
Секретарь имеет только частичный доступ к полям объекта, например, редактирует входящий номер.
В этом случае, видимо, необходимо реализовывать список доступа к полям объекта.
Да, можно реализовать список доступа к полям объекта
А можно сделать разные UI объекта — для создания один, а для редактирования — другой. В документообороте, по крайней мере, это хорошо ложиться на требования. Регистратор по правам мог бы изменить эти поля, но вот «чисто случайно» их в UI при регистрации нету. И наоборот.
Но если система имеет API — то в этом случае, конечно, в нём будет дырка :)
Проще тогда доступ давать не к объекту, а к его представлению. Одно представление для секретаря, другое для руководителя, третье для прочих лиц.
Насколько понял TreeSupport — это кеширование всех прав доступа всех пользователей на все ресурсы.

В своем варианте («Дьявольский» ACL — мой вариант проверки прав) я решил таким образом: при запросе сначала проверяю по этим кешируемым данным и если в них нет, тогда запускаю долгий алгоритм определения, после которого записываю результат в кеш. В этом случае TreeSupport строиться по мере необходимости. И при изменении прав не нужно его полностью перестраивать. Однако я кеширую результат доступа на ресурс для группы, а не для конкретного пользователя.
за ссылку спасибо, зачитаю )
Но TreeSupport — это другое. Это именно развертка иерархической структуры в плоскую, там НЕ содержатся права по отношению к объектам, иначе она была бы слишком здоровая и тормозная.
Грубо говоря, связь Группа -> Пользователь И Группа -> Группа там содержатся, но не Объект -> Группа и не Объект -> Пользователь
>>развертка иерархической структуры в плоскую
В общем то это и получается типа кеширования. По крайней мере в моем понимании. Т.е. все права заданы в иерархической форме, а в таблице для быстрой выборки это все плоском виде храниться.

>>там НЕ содержатся права по отношению к объектам
это значит я не разобрался.Я просто поглядел запрос join, там фигурирует и пользователь и Id какие-то (ObjectId и SecuritySubjectId) и запрашиваемая операция a.CanRead = 1, вот и решил что таблица содержит права на ресурсы. Нужно будет внимательнее почитать. :)
Зависимые списки доступа — в первую очередь организационная проблема. Ну а далее обычно — добавление нужных групп в ACL.

Последние две проблемы решаются легко — не используйте в ACL конкретных пользователей. Создайте для каждого отдельную группу и делегируйте полномочия через неё. Иногда можно сделать несколько групп для передачи части полномочий.
Only those users with full accounts are able to leave comments. Log in, please.