Как просто обезопасить сущности на бэкэнде? - PullRequest
0 голосов
/ 03 марта 2019

Интересно, есть ли полезные практики, как защитить сущности на бэкэнде, не извлекая все время корневые сущности.

Допустим, у вас есть приложение (например, Spring Boot + MySQL) со следующими сущностями:

  • Пользователь : у каждого может быть много project или ни одного вообще.
  • Проект : каждый принадлежитПользователь и может иметь много Элементов или ни одного вообще.
  • Элемент : каждый из них принадлежит Проекту и может иметь много Комментариев или вообще никого.
  • Комментарий : каждый из них принадлежит к Предмету или вообще никому.

Что-то классическое, например

User --> Project --> Item --> Comment

Интересно, как эффективно проверить, если пользовательимеет право, например, удалить Comment.

Моей первой идеей будет присоединиться обратно к Project и затем проверить, имеет ли пользователь право изменять этот проект.

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

В-третьих, я думаю, что база данных, ориентированная на документы, может быть лучше, чем классическая MySQL / MariaDB.

Поэтому мой вопрос заключается в том,Есть ли концепция или, может быть, конкретная реализация / библиотека / пример, как решить эту проблему?

1 Ответ

0 голосов
/ 06 марта 2019

Как обычно, «это зависит».

Кажется, вы упростили свое требование.Просто чтобы прояснить:

  • Комментарий относится только к одному элементу.
  • Предмет принадлежит ровно одному проекту.
  • Проект принадлежит ровно одному пользователю.
  • У пользователя ноль или более проектов.
  • Проект содержит ноль или более элементов.
  • Элемент имеет ноль или более комментариев.

Вопрос, на который вы хотите ответить, заключается в следующем: имеет ли конкретный пользователь к нему доступ, основываясь на структуре данных выше?

Вы не указываете количество записей или точное определение «эффективного», но я предполагаю, что вы не говорите об уровнях данных Facebook, а «эффективный» означает «быстрый».

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

Вариант 2 - денормализация в таблицу сопоставления - почти наверняка будет ненужным и может быть медленнее, поскольку вам нужно поддерживать таблицу сопоставления, которая нене свободен.

Вариант 3 будет иметь смысл;Вы также можете взглянуть на графическую базу данных.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...