Контроль доступа к частям системы, но также к некоторым частям информации

Question

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

• У нас есть пользователи и группы. Пользователь может принадлежать многим группам (отношение многих к большому числу)
• Есть определенные части сайта, которым требуется управление доступом, но:
• Есть определенные ROWS определенных таблиц, которым требуется управление доступом, т.е. определенный пользователь (или определенная группа) не должен удалять определенную строку, но другие строки одной и той же таблицы могут иметь разные настройки разрешения для этого пользователя (или группы)

Есть ли простой способ это сделать? Мы что-то упускаем?

Нам нужно реализовать это в python (если это любая помощь).

Answer 1

1) создать таблицу с правами, то есть удаление, обновление и т.д.

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

3) проверьте связь в сводной таблице, прежде чем разрешить операцию продолжить.

ваша таблица прав может выглядеть следующим образом:

ID RIGHT 
1 DELETE 
2 UPDATE 

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

ID TITLE   CONTENT 
1 blog entry 1 This is a blog entry 
2 blog entry 2 This is another blog entry 

и вашей пользовательской таблицы может быть:

ID NAME 
1 Bob 
2 Alice 

Затем в сводной таблице будет как

ID USER_ID RIGHT_ID BLOG_ID 
1 1  2  1 
2 2  1  1 
3 2  2  1 
4 2  1  2 
5 2  2  2 

Это означает, что Боб может обновить только запись в блог 1, но Алиса может изменить или удалить либо запись в блоге

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

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

Answer 2

Эта проблема не совсем новая; это в основном общая проблема авторизации и прав доступа/контроля.

Чтобы избежать необходимости моделировать и поддерживать полный график того, какие объекты могут иметь каждый пользователь, каждый из них может принимать решения (в зависимости от того, что делает ваше приложение) о том, как начать царить в мультипликативном масштабных факторов. Итак, во-первых: где пользователи получают свои права? Если каждый пользователь имеет индивидуально назначенные права, вы ставите значительную проблему управления ongoig тем, кто должен добавлять пользователей, изменять пользователей и т. Д.

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

Теперь, как выглядят эти права? По-видимому, нецелесообразно назначать права на целевой объект по объектам. Таким образом, возможно, права следует рассматривать как набор абстрактных «карточек доступа». Объекты в системе могут быть помечены как требующие «синий» доступ для чтения, «красный» доступ для обновления и «черный» доступ для удаления. Эти абстрактные права могут быть организованы в какой-то топологии, так что наличие «черного» доступа означает, что вы неявно также имеете «красный» и «синий», или, может быть, все они не пересекаются; это зависит от вас и от того, как ваше приложение должно работать. (Заметим также, что вы можете захотеть рассмотреть такие типы объектов — столы, если вам нравится —, может потребоваться их собственное правило доступа, по крайней мере, для «создания».

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

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

Answer 3

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

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

Answer 4

Добавить дополнительную таблицу «категория» или «тип» в таблицу (таблицы), которая будет классифицировать строки (или, если хотите, группировать/сгруппировать их), а затем создать сводную таблицу, которая определяет контроль доступа между (rowCategory, userGroup). Поэтому для каждой строки по ее категории вы можете вытащить доступ к пользовательским группам (и какой доступ).