MySQL - структура для разрешений на объекты - PullRequest
Новая
       27

MySQL - структура для разрешений на объекты

2 голосов
/ 13 июня 2010

Какая была бы идеальная структура для пользователей> прав доступа к объектам.

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

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

Group 1
    Group 2
    Group 3
    Group 4
Group 5
   Group 6
Group 7
   Group 8
       Group 9
       Group 10

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

Если у кого-то есть разрешение на группу, я должен иметь возможность предоставить ему разрешения на все подгруппы ИЛИ ограничить его только этой группой.

Моя текущая мысль - создать таблицу пользователей, а затем таблицу разрешений с такими столбцами, как: 

permission_id (int) PRIMARY_KEY
user_id (int) INDEX
object_id (int) INDEX
type (varchar) INDEX
admin (bool)
read (bool)
write (bool)
edit (bool)
delete (bool)

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

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

Так, в качестве вопроса, я должен использовать вышеупомянутую структуру?Или кто-то может направить меня в сторону лучшего?

РЕДАКТИРОВАТЬ

Альтернативой является создание таблицы разрешений для каждого типа объекта.

1 Ответ

2 голосов
/ 14 июня 2010

Я предлагаю вам добавить отметку времени «last_update» и столбец «last_updated_by_user», чтобы у вас была надежда отслеживать изменения в этой таблице в вашей работающей системе.

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

Будьте осторожны с «необходимостью быстро масштабироваться».Без реального производственного опыта трудно угадать, в чем действительно нуждается масштабная система.

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

Кажется, ваша схема связывает пользователей с объектами.Вы хотите, чтобы ваш первичный ключ и ваш уникальный индекс были (user_id, object_id)?То есть вы хотите, чтобы у каждого пользователя была либо ноль, либо одна запись разрешения для каждого объекта?Если это так, используйте первичный ключ для обеспечения этого, а не предлагаемый суррогатный ключmission_id.

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

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

  2. это также предоставляет доступ ко всем подобъектам.

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

Второй вариант затрудняет определение того, имеет ли пользователь доступ к определенному объекту, потому что вам нужно пройти иерархию объектов к корню дерева в поисках разрешений на доступ.родительские объекты при проверке, есть ли у пользователя доступ.Эта проблема производительности должна доминировать в принятии решений.Будут ли ваши пользователи создавать несколько объектов и часто получать к ним доступ?Или они создадут много объектов и подобъектов и получат к ним доступ редко?Если доступ чаще, чем создание, вам нужен первый выбор.Возьмите удар по предоставлению разрешений во время создания объекта, а не по поиску разрешений во время доступа к объекту.

Я думаю, что первый выбор, вероятно, лучше.Я предлагаю этот макет таблицы: 

user_id (int)
object_id (int)
type (varchar)  (not sure what you have this column for)
admin (bool)
read (bool)
write (bool)
edit (bool)
grant (bool)
delete (bool)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id.

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

user_id (int)
object_id (int)
permission_enum (admin/read/write/edit/grant/delete)
type (varchar)  (not sure what you have this column for)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id, permission_enum
...