ColdFusion: варианты применения, основанные на роли? - PullRequest
1 голос
/ 10 июля 2011

Я понимаю, как ограничить целые страницы или даже компоненты путем реализации <cflogin> и ролей.Например:

<cfif IsUserInRole("Admin") OR IsUserInRole("Accounting")>
    ...You can view this page...
<cfelse>
    ...You can not view this page...    
</cfif>

Но как рекомендуется ограничивать некоторые аспекты страницы?Например, «Администратору» разрешено отправлять Глобальные сообщения всем пользователям, но эта опция недоступна для обычного «Пользователя»

. Полагаю, я мог бы использовать Сессию для манипулирования своими представлениями (страницами).Как это обычно обрабатывается?

Ответы [ 2 ]

6 голосов
/ 11 июля 2011

Вы правы, защита страницы и защита элементов разные.

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

Важно иметь все три:

  1. Пользователи
  2. Роли
  3. Разрешения <- это то, что вам не хватает </li>

Разрешения - это то, что защищает элементы и страницы, , а не роли или пользователи Ваш код не должен иметь никакого представления (потому что это не нужно), какие есть пользователи или роли - только имена разрешений.

Когда пользователь входит в систему, я беру его роль (и). Затем я беру все разрешения, которые назначены этим ролям (просто список строковых значений).

Например, на странице у меня может быть:

  • Добавить товар
  • Просмотр товара
  • Удалить элемент

Когда я кодирую эту страницу, я на самом деле защищаю каждый из этих элементов с помощью строк разрешений, называемых схожими (addItem, viewItem, deleteItem).

<cfif listContainsNoCase( session.permissions, 'addItem' )>
    <!--- code to add item --->
</cfif>

(Примечание. Я рекомендую использовать для этого пользовательский тег или функцию, но для примера вышеописанное работает нормально).

Если вы сделаете это таким образом, это обеспечит максимальную гибкость и абстракцию. Если вы защищаете элементы на основе ролей, вы ограничиваете себя:

  • Добавление новых ролей потребует большого количества изменений кода!
  • Изменение разрешений между ролями требует большого количества изменений кода!

Если вы сделаете это, как упомянуто выше, вам никогда не потребуется изменять код безопасности в базе кода, потому что разрешение «addItem» всегда должно быть в логике «добавления элемента», верно? :)

Теперь, если вам нужно создать роль типа «менеджер», которая имеет все роли пользователя и несколько прав администратора, вы просто создаете эту роль и назначаете ей правильные разрешения (возможно, addItem и editItem, но не deleteItem). Бам! Теперь у меня есть роль менеджера, которую можно назначать пользователям с без изменений кода !

Если бы я посыпал свой код типом "является пользователем эта роль" - мне пришлось бы везде редактировать свой код, чтобы разрешить мою новую роль "менеджер" - черт!

Имеет смысл?

=) * 1 054 *

0 голосов
/ 03 декабря 2013

Ситуация начинает складываться, когда предприятиям нравится менять разрешения, которые часто имеют Роли, потому что они не знают, как еще дать кому-либо права на что-либо.

Итак, допустим, что пользователь в маркетинге хочет, чтобы права на «обновление» выполняли какую-то задачу. Кто-то в бизнесе дает им разрешение на обновление. Но у ИТ-менеджера также есть права на «обновление», что дает ему доступ к вещам, которых не должно иметь разрешение на обновление для маркетинга.

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

...