Как лучше всего обрабатывать несколько типов разрешений?

Я согласен с Джоном Дауни.

Лично я иногда использую помеченное перечисление разрешений. Таким образом, вы можете использовать побитовые операции AND, OR, NOT и XOR для элементов перечисления.

"[Flags]
public enum Permission
{
    VIEWUSERS = 1, // 2^0 // 0000 0001
    EDITUSERS = 2, // 2^1 // 0000 0010
    VIEWPRODUCTS = 4, // 2^2 // 0000 0100
    EDITPRODUCTS = 8, // 2^3 // 0000 1000
    VIEWCLIENTS = 16, // 2^4 // 0001 0000
    EDITCLIENTS = 32, // 2^5 // 0010 0000
    DELETECLIENTS = 64, // 2^6 // 0100 0000
}"

Затем можно объединить несколько разрешений с помощью побитового оператора AND.

Например, если пользователь может просмотреть & edit users, двоичный результат операции-0000 0011, который преобразуется в десятичный - 3.
Затем вы можете сохранить разрешение одного пользователя в одном столбце вашего DataBase (в нашем случае это будет 3).

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

Способ, которым я обычно иду о кодировании систем разрешений, состоит в том, чтобы иметь 6 таблиц.

• Пользователи - это довольно прямолинейно это ваша типичная таблица пользователей
• Группы-это будет синонимично вашим отделам
• Роли-это таблица со всеми разрешениями, как правило, также включающая понятное человеку имя и описание
• Users_have_Groups - это таблица many-to-many того, к каким группам принадлежит пользователь
• Users_have_Roles - еще одна таблица many-to-many о том, какие роли назначаются отдельному пользователю
• Groups_have_Roles-итоговая таблица many-to-many о том, какие роли есть у каждой группы

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

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

В дополнение к решениям Джона Дауни и jdecuyper, я также добавил бит "Explicit Deny" в конце / начале битового поля, так что вы можете выполнять аддитивные разрешения по группе, членству в роли, а затем вычитать разрешения на основе явных запрещающих записей, так же как и NTFS работает с правами доступа.

Честно говоря, функции членства / ролей ASP.NET идеально подходят для описанного вами сценария. Написание собственных таблиц / procs / классов-это отличное упражнение, и вы можете получить очень хороший контроль над мельчайшими деталями, но после того, как я сделал это сам, я пришел к выводу, что лучше просто использовать встроенный материал .NET. Большая часть существующего кода предназначена для работы вокруг него,что очень хорошо. Написание с нуля заняло у меня около 2 недель, и это было далеко не так надежно, как раньше .NETs. Вы должны кодировать так много дерьма (восстановление пароля, автоматическая блокировка, шифрование, роли, интерфейс разрешений, тонны процессоров и т. д.), И это время можно было бы лучше потратить в другом месте.

Извините, если я не ответил на ваш вопрос, я похож на парня, который говорит, чтобы узнать c#, когда кто-то задает вопрос vb.

Подход, который я использовал в различных приложениях, заключается в том, чтобы иметь универсальный класс PermissionToken, который имеет свойство изменяемого значения. Затем вы запросите запрошенное приложение, и оно сообщит вам, какие PermissionTokens необходимы для его использования.

Например, приложение доставки может сообщить вам, что ему нужно:

new PermissionToken()
{
    Target = PermissionTokenTarget.Application,
    Action = PermissionTokenAction.View,
    Value = "ShippingApp"
};

Очевидно, что это может быть расширено для создания, редактирования, удаления и т. д. и, благодаря свойству custom Value, любое приложение, модуль или виджет могут определять свои собственные необходимые разрешения. YMMV, но это всегда был эффективный метод для меня, который я нашел хорошо масштабируемым.