Секретный вопрос: как защитить коллекции Hibernate, возвращающиеся с клиента на сервер?

Question

У меня есть простое pojo с именем «Parent», которое содержит коллекцию объекта «Child».

В hibernate / jpa это просто связь один-ко-многим, дети не знают своего родителя: у этих дочерних объектов может быть другой тип Parent, поэтому проще не знать родителя (представьте, что Child представляет теги у родителей могут быть разные типы объектов, у которых есть теги).

Теперь я отправляю свой родительский объект в представление клиента моего веб-сайта, чтобы позволить пользователю изменять его.

Для этого я использую Hibernate / GWT / Gilead.

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

Подводя итог, когда родительский объект возвращается на сервер, он теперь имеет в своей коллекции: - новые "дочерние" объекты, где id равен нулю и должен быть сохранен - модифицированные дочерние объекты, где id не равен NULL и должен быть объединен - потенциально взломанные «дочерние» объекты, где id не нулевой, но изначально не принадлежит родительскому объекту - Дочерние объекты отсутствуют (удалены): необходимо удалить

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

спасибо

PS: простите за мой английский, надеюсь, вы поняли концепцию;)

Answer 1

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

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

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

Удачи. Я рекомендую вам нарисовать подробную блок-схему вашей логики, прежде чем вы начнете слишком много писать.

Answer 2

Лучшее решение, которое я нашел, - это управление DTO, созданным вручную. DTO отправляет клиенту только необходимые данные. Для каждого поля, которое я хочу установить в режиме ReadOnly, я вычисляю сигнатуру на основе секретного ключа, который я посылаю клиенту с моим dto.

Когда мой DTO возвращается на сервер, я проверяю подпись, чтобы убедиться, что мои поля только для чтения не изменились (пересчитать подпись с возвращающимися полями и сравнить ее с подписью, возвращающейся с dto)

Позволяет указать поля только для чтения и быть уверенным, что мои объекты не взломаны.