Контроль доступа в ASP.NET MVC с использованием [Flags] на основе Enum для управления разрешениями int в SQL

Я бы сказал нет.

1. Вы предполагаете, что вам понадобится не более 32 (или 64, если вы используете bigint) привилегии. Для меня это звучит произвольно. Перемещение к varbinary в базе данных может преодолеть это, но тогда ваше перечисление будет вверх по ручью (не может создавать перечисления на byte[])! И вы не сможете проводить числовые сравнения.

2. Вы предполагаете, что привилегия 0x1 всегда будет логически меньше, чем 0x2, 0x80 и так далее. По моему опыту, такое бывает редко. Чаще всего привилегии совершенно независимы друг от друга (то есть: наличие привилегии «добавить пользователя» не имеет ничего общего с привилегией «загружать изображение»; одна группа пользователей (администраторы) будет иметь первое, а другие (издатели контента) будут иметь Это означает, что ваше числовое сравнение не так полезно, как вы думали вначале.

3. То, что вы делаете, может дать выигрыш в производительности, но вы еще не продемонстрировали, что существует проблема с производительностью! Большинство моих систем привилегий работают с одной записью в базе данных для каждого пользователя, чтобы предоставить или запретить каждую привилегию. Получение 100 записей не требует больших затрат на мою базу данных. Лучше просто кэшировать разрешения каждого пользователя между запросами, чем использовать битовую маску.

4. Что касается производительности обновления: как часто все равно меняются разрешения пользователей? По моему опыту, когда система установлена, они, как правило, становятся довольно статичными.

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

Обратите внимание, что я использовал эту технику при записи статистики действий пользователя (отслеживая, какие элементы пользователи находят при поиске, какие объекты они просматривают и т. Д.). Моя причина заключалась исключительно в том, чтобы убедиться, что длина записей базы данных была фиксированной и небольшой, чтобы вставка была быстрой. И я не делал числовых сравнений. (И, честно говоря, я никогда не проверял, есть ли разница между int столбцом и несколькими bit столбцами).

ИЗМЕНИТЬ. Базовая альтернатива (которую я использую): отношение M: N между пользователями и привилегиями (я называю их правами).

(Прошу прощения за уши Микки Мауса на моем пользователе!)

Наличие записи в UserRight указывает на то, что этому пользователю предоставлено право. Отсутствие указывает на отсутствие права. Этот запрос дает вам все права, назначенные пользователю.

SELECT [dbo].[User].Username, [dbo].[Right].Id, [dbo].[Right].Name
FROM [dbo].[Right]
INNER JOIN [dbo].[UserRight] ON [dbo].[Right].Id = [dbo].[UserRight].RightId
INNER JOIN [dbo].[User] ON [dbo].[User].Id = [dbo].[UserRight].UserId
WHERE [dbo].[User].Id = @pUserId

Затем в коде для подтверждения права пользователя:

var grantedRights = RunTheAboveQuery(currentUser.Id);
if (grantedRights.Any(r => r.Id == requiredRight))
    // User has the right.
else
    // User does not have the right. 

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

Это не искусственно ограничивает количество привилегий, поддерживаемых вашей системой. И он не предполагает каких-либо отношений между привилегиями (поэтому вы не можете проводить числовые сравнения; в моей системе все выполняется IEnumerable<Right>). И, если вам действительно нравятся битовые маски, вы можете создать Dictionary<User, BitArray> в кеше!

У меня также есть концепция Role, которая предоставляет пользователям логическую группу прав. Это просто еще одна таблица M: N. Это упражнение для читателя!

В общем, размещение нескольких значений (флагов) в одном поле - плохая идея.

Если вы планируете проводить аудит этих данных, это действительно плохая идея, поскольку сложно эффективно определить, какие флаги меняются от обновления к обновлению.

Проблемы, с которыми вы можете столкнуться, даже если не проводите аудит.

• Многие простые запросы (какие пользователи используют авторизацию DeleteThis) не являются SARGable, потому что вам необходимо выполнить побитовая операция перед сравнением.

• Также select users from permissions where security < DBAceessRights.DetailRead может не возвращать правильные результаты, потому что AppearInListing & CreateNew больше, чем DetailRead, но не имеет включенного DetailRead. Таким образом, выгода, на которую вы надеялись, вы можете не получить

• Управление параллелизмом (множественные записи в ACL) сложнее, поскольку изменение одного «логического значения» фактически изменяет все значения.