Контроль доступа на основе ролей - должен ли я иметь список разрешений в БД или просто в коде (например, enum)? - PullRequest
Новая
       6

Контроль доступа на основе ролей - должен ли я иметь список разрешений в БД или просто в коде (например, enum)?

0 голосов
/ 20 октября 2011

Обычно при реализации какого-либо контроля доступа на основе ролей мы имеем следующие хорошо известные концепции:

  • Роль
  • Пользователь
  • Разрешение

И пользователям будут назначаться роли, каждая из которых имеет набор разрешений (для выполнения операции / доступа к ресурсу и т. Д.).Таким образом, пользователи получают разрешения на выполнение операций, назначаясь одной или нескольким ролям (которым был назначен набор разрешений).

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

Я думаю, что если набор возможных разрешений / операций изменится - это потребует внесения изменений в код и перекомпиляции любым способом, поэтому наличие справочной / справочной таблицы в базе данных выиграетна самом деле не предоставляет никакого значения, кроме того факта, что администратор БД мог бы выполнить быстрый SQL-запрос для получения списка всех разрешений, используемых приложением.

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

Учитывая это, есть ли какая-либо причина иметь таблицу базы данных, представляющую список возможных разрешений (кроме того факта, что некоторым, вероятно, легче смотретьв БД, а не копаться в коденайти список / перечень разрешений)?

1 Ответ

0 голосов
/ 20 октября 2011

Контрольный список: 1) Вам нужно вносить изменения, когда веб-сайт находится в сети, без простоев?2) Будете ли вы использовать встроенную роль / поставщика услуг?3) Вы хотите использовать атрибуты (например, mvc [Authorize]) и т. Д.?4) Вы хотите, чтобы пользователи могли программно изменять разрешения / роли?

Любое из вышеперечисленных средств означает, что вы должны хранить информацию в БД.

Для небольших приложений я предпочитаю просто создать несколькостатические методы, которые также используют какое-то наследование, например: 

 isadmin()
 {
     if (usernameArray.Contains[currentname]) 
         return true;
     [...]
 }

 ispublisher()
 {
    if (isadmin()) return true;
     [...]
  }

и таблицу с разрешениями для каждого псевдокласса пользователя.

Обновление : схема БД дляопределенный доступ: (* является ключом, & является внешним ключом) 

 Users:
 Username *
 [...]


 UserClasses (EG: admin...)
 ID *
 description

 AccessTypes  (EG: can delete)
 ID *
 description

 UserClassesAssign
 classid *&
 username *&

 AccessPerClass
 accessid *&
 classid *&

Таким образом, в любое время, когда вы хотите увидеть, может ли 'username' 'CanDelete', вы должны проверить, связано ли пользовательское 'username'к любым классам, которые связаны с доступом 'CanDelete', и эти ссылки, конечно, могут изменяться во время выполнения

...