Pull to refresh

Comments 9

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

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

Последние две проблемы решаются легко — не используйте в ACL конкретных пользователей. Создайте для каждого отдельную группу и делегируйте полномочия через неё. Иногда можно сделать несколько групп для передачи части полномочий.
Sign up to leave a comment.

Articles