Как предотвратить изменение отношений между сущностями?

Question

Я использую весеннюю загрузку для хранения сложных json-структур через JPA в нашей базе данных.

Корень json-структуры представляет объект "Дом".Объект "Дом" содержит несколько предметов мебели.Например:

House ID: 4711
|- Furniture: ID 4712 (with confidential information)

Пользователи имеют разрешения на чтение / запись для определенных Домов и всех их «Мебели».

Моя проблема в том, что через REST-API пользователь может "украсть «Мебель из других домов», если он знает их первичные ключи;с таким запросом:

POST http://localhost:8080/house

{
    houseId: 99991337,
    furnitures: [{
        furnitureId: 4712,
        ...
    }]
}

Это приводит к:

House ID: 4711
|- empty!

House ID: 99991337
|- Furniture 4712 (with confidential information)

Хотя у пользователя не было разрешения на дом 4711, он «связал» Мебель 4712 из дома 4711 и вместо этогосвязал его с Домом 99991337.

Как я могу запретить смену Дома Мебели?

В организациях JPA существуют двусторонние отношения OneToMany-От дома до мебели.Я подумал, может быть, поиск в базе данных любой мебели входящих запросов, проверить все разрешения на все из них.Но я бы предпочел только проверить разрешение на Дом (потому что в реальной жизни у меня есть гораздо больше сущностей, таких как Мебель)

Answer 1

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

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

Answer 2

Я думаю, вы можете попробовать обработчик обновления таблицы сущностей Furniture с аннотацией @HandleBeforeSave и @RepositoryEventHandler, и внутри этого обработчика вы можете запросить только эту сущность Furniture и проверить, к какой House она принадлежит.А затем решите, что делать с этим запросом на обновление

Answer 3

Если верно следующее утверждение:

Yes, a furniture should belong to exactly one house and should be privately be owned by that house. Only those users permitted to see/edit the house should be able to see/edit its furniture.

На мой взгляд, это означает, что вам нельзя разрешать создавать дом с мебелью, которая уже прикреплена к другому дому (Бизнестребование).

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

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

Answer 4

Если мое понимание верно, просто найдите таблицу разрешений по userId и houseId, которые были предоставлены в запросе.Если есть совпадение, то у пользователя есть права на изменение houseId.

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

Если вы все еще хотите, чтобы пользователь изменил furniture data, вы можете сохранить только furniture сущность, указав furnitureId и text для объекта new Furniture().