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

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

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

как насчет создания таблицы разрешений, а затем таблицы UserPermission для хранения взаимосвязей?

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

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

UserID | Permission
===================
1      | 1              1 representing manage users
1      | 2              2 being manger products
2      | 3 

Такой способ будет легче поддерживать и добавлять позже.

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

PermissionID | Description
==========================
1            | Manage Users
2            | Manager Products

Обычно у меня есть таблица Users, таблица Roles и таблица UserRoles. Таким образом, у вас может быть неограниченное количество ролей без изменения структуры базы данных, а пользователи могут быть в нескольких ролях.

Я заставляю приложение авторизоваться только для ролей (а не для пользователей). Обратите внимание, что столбец «id» в таблице ролей не является столбцом идентификаторов. Это связано с тем, что вам может потребоваться контролировать идентификаторы, которые помещаются в эту таблицу, потому что вашему приложению придется искать определенные идентификаторы.

Структура выглядит так:

create table Users (
 id int identity not null,
 loginId varchar(30) not null,
 firstName varchar(50) not null,
 etc...
)

create table Roles (
 id int not null,
 name varchar(50) not null
)

create table UserRoles (
 userId int not null,
 roleId int not null
)

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

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

Я бы предложил абстрагировать разрешения вашего веб-приложения с помощью концепции поставщика ролей. Начиная с версии 2.0, это предоставляется в .NET как System.Web.Security.RoleProvider.

Основная идея состоит в том, что вы используете существующую структуру, записывая свои проверки разрешений в соответствии с ней, а не конкретным механизмом хранения. Затем вы можете подключить любой доступный механизм хранения, будь то XML-файл, база данных или даже хранилище авторизации с помощью диспетчера авторизации программного обеспечения Windows (который позволяет легко привязать свои пользовательские разрешения к LDAP, как один пример - код для настройки не требуется).

Если вы решите использовать базу данных в качестве механизма хранения, поддерживаются несколько баз данных для автоматического создания базовых таблиц, которые необходимы платформе. Это включает запуск .NET на Mono и использование модели поставщика ролей поверх MySQL.

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

РЕДАКТИРОВАТЬ: я также должен указать, что настройка того, как ваше веб-приложение связано с механизмом хранения, выполняется через файл web.config и не требует изменения кода. Я нашел это очень полезным для тестирования производственной версии кодовой базы на моем локальном компьютере с использованием XML-файла для имитации разрешений вместо обычного поставщика базы данных - и все это путем изменения двух строк в web.config.

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

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

Если вы думаете, что когда-нибудь вам может понадобиться выразительность, я бы выбрал систему полного ACL (списка контроля доступа) с пользователями и группами (или ролями). То есть каждая вещь, управляемая разрешениями (например, «управление пользователями», «управление продуктами»), имеет ACL, который представляет собой список всех пользователей и групп, имеющих к нему доступ. Затем пользователи либо добавляются непосредственно в соответствующие ACL, либо добавляются в группу, которая уже является членом ACL.

Хотя ACL предлагает реализацию списка, вам будет лучше с таблицей; этот ответ - хороший способ.

Не могу комментировать, потому что я новичок в SO, но что касается принятого ответа - огромное преимущество, которое дает это решение, - это возможность универсально обрабатывать разрешения, а не только операторы if повсюду в коде, а также специальные возможности например, временные разрешения (разрешения, срок действия которых истекает)

Разрешения обычно представляют собой ключевые слова с 1, 0 или нулем (что указывает на наследование). С битовой системой вы, вероятно, не сможете создавать индексы по идентификатору пользователя и ключевому слову разрешения; вместо этого вам придется сканировать каждую запись, чтобы получить значение разрешения.

Я бы посоветовал выбрать первый вариант. Мне кажется, лучшее решение:

create table permissions (
    user_id INT NOT Null,
    permission VARCHAR(255) NOT NULL,
    value TINYINT(1) NULL
)
alter table `permissions` ADD PRIMARY KEY ( `user_id` , `permission` )