Где и как хранить разрешения пользователей? - PullRequest
1 голос
/ 04 марта 2012

Допустим, моя система состоит из двух типов бизнес-объектов: проектов и пользователей .

В соответствии с разрешением пользователя он / она может:

| Action          | Role             |
|-----------------|------------------|
| view projects   | Clients          |
| edit projects   | Devs             |
| manage projects | Managers         |
| manage users    | Administrators   |

Проблема в том, что клиенты могут видеть только некоторые конкретные проекты. Проекты могут быть либо общедоступными (их видят все), либо они могут быть видны определенным конкретным клиентам.

Как и в случае с разработчиками, разработчик может редактировать как свои собственные, так и другие проекты, заданные менеджером. Менеджер должен иметь возможность создавать и управлять пользователями / проектами, если только администратор специально не откажет этой возможности менеджеру по конкретным проектам. Администраторы имеют полный доступ к управлению всем в системе, включая всех пользователей и все проекты.


Это почти то, чего я пытаюсь достичь. «Как» это то, что беспокоит меня.

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

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

Это будет выглядеть так:

| user_id | access  | object_type | object_id |
|---------|---------|-------------|-----------|
| 45      | allowed | user        | 42        | user 45 can manage user 42
| 42      | denied  | project     | 30        | user 42 cannot do anything with
                                                project 30

Таблица должна использоваться с ролями пользователя. Например, если пользователь 45 является клиентом , он не может ничего сделать для пользователя 42 (даже если правило все равно существует).


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

Итак, актуальные вопросы:

  • Это хорошая идея?
  • Есть ли лучшая система?
  • Любые другие предложения?

1 Ответ

1 голос
/ 05 марта 2012

Что составляет эти проекты ??Базы данных, файлы и папки или что?

Это проекты баз данных проектов или что-то еще?

база данных Кратко

CREATE USER 'monty'@'localhost' IDENTIFIED BY 'some_pass';


GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%';
GRANT ALL PRIVILEGES ON project1.* TO 'user1'@'%';
GRANT ALL PRIVILEGES ON project2.* TO 'user2'@'%';

Опционально WITH GRANT OPTION;


Если эти проекты содержат файлы и папки, вам следует использовать разрешения файловой системы.Какую операционную систему и файловую систему вы используете?Файловые системы Linux.

chgrp  (change group)
chown   (change owner)
...