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