Структура аутентификации пользователя и таблица разрешений - PullRequest
Новая
       19

Структура аутентификации пользователя и таблица разрешений

2 голосов
/ 13 октября 2011

Я создаю библиотеку аутентификации пользователя (для упражнения).

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

Каждая роль имеетнабор разрешений (например, editUser, createUser и т. д.).

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

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

Я думал 

users            : ID            | username | etc  
groups           : ID            | name     | etc  
user_group       : group_ID      | user_ID  
permissions      : ID            | name     | description (lookup table)
group_permission : permission_ID | group_ID

и, в принципе, если у группы есть разрешение, тогдаполучает запись в group_permission.

У меня такой вопрос, является ли это наиболее продуктивным способом сделать это, или мне лучше иметь каждое разрешение в виде столбца в таблице групп и отбросить таблицу group_permission?

1 Ответ

1 голос
/ 13 октября 2011

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

Это позволяет вам разрешить доступ ко всем учетным записям, кроме .....
Если вы делаете это наоборот, вы должны разрешить доступ к каждому объекту, не используя данные HR.
Первый способ устанавливает разрешения для 2 объектов (1 разрешение для родителя, 1 исключение для дочернего элемента), второй способ может использовать десятки разрешений.

Лично я бы обновил таблицу permissions, включив в нее также исключения.
Это позволит вам прикреплять исключения как к группам, так и к пользователям.

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

CREATE TABLE bh_permission (
  user_or_group_id unsiged integer not null,
  isuser ENUM('user','group') not null default 'user',
  permission_description varchar(255) not null,
  allow_or_not ENUM('allow','forbid') not null default 'allow'
) ENGINE = BLACKHOLE;

Теперь вы можете вставить в таблицу указание либо group, либо user_id 

INSERT INTO bh_permission VALUES ('123','group','p_HR_files_2011','forbid');

и иметь триггер для обработки технических деталей: 

DELIMITER $$

CREATE TRIGGER ai_bh_permission_each AFTER INSERT ON bh_permission FOR EACH ROW
BEGIN
  DECLARE Mypermission_id INTEGER;
  //like is always case-insensitive, `=` is not.
  SELECT p.id INTO Mypermission_id FROM permissions p 
    WHERE name LIKE NEW.permission_description LIMIT 1;
  IF isuser = 'user' THEN
    INSERT IGNORE INTO user_permission (user_id, permission_id, allow_or_not)
      VALUES (NEW.user_or_group_id, Mypermission_id, NEW.allow_or_not);
  ELSE
    INSERT IGNORE INTO group_permission (group_id, permission_id, allow_or_not)
      VALUES (NEW.user_or_group_id, Mypermission_id, NEW.allow_or_not);
  END IF;
END $$

DELIMITER ;
...