У меня есть несколько тесно связанных проблем в Весенняя безопасность. Я разрабатываю с использованием Spring Boot и использую Весенние данные REST для создания конечных точек REST непосредственно из моих репозиториев.
У меня есть несколько объектов, и требуется, чтобы все эти объекты были конечными точками REST. Я позволяю spring-data-rest управлять созданием этих конечных точек, и я защищаю эти конечные точки, добавляя @PreAuthorize и @PostAuthorize в методы репозитория сущностей по мере необходимости. Это прекрасно работает, когда я вызываю конечную точку, например /entity/id.
Но я сталкиваюсь с проблемами отсюда. Допустим, у меня есть 2 объекта, Entity1 и Entity2, и у них есть отношения One to One. Spring data rest позволяет мне получать связанные данные Entity2 с Entity1, например /entity1/id/entity2. Но у меня разные права доступа к Entity1 и Entity2, и при вызове указанной выше конечной точки проверяются только права доступа, установленные в репозитории только для Entity1. Таким образом, если у пользователя есть доступ к таблице Entity1 и нет доступа к таблице Entity2, он все равно может видеть некоторые данные Entity2 через отношение внешнего ключа Entity1. Это правильный дизайн?
Кроме того, у нас есть несколько пользовательских конечных точек API, в которых мы должны агрегировать данные из нескольких репозиториев сущностей. Кроме того, сами эти конечные точки должны быть защищены. Итак, я использую @PreAuthorize вместо метода конечной точки. Это работает, как и ожидалось, и метод конечной точки вызывается только тогда, когда выражение допустимо. Но когда вызывается метод репозитория (конечно, через класс обслуживания), @PreAuthorize по этому методу репозитория также оценивается. Я хотел бы, чтобы проверка была сделана с в начале. Возможно ли это сделать?
Любые предложения по улучшению дизайна также приветствуются.
Не существует простого решения без масштабного изменения/переопределения множества функций Spring DataRest по умолчанию. Я работаю с таким пакетом уже много лет, и он работает очень хорошо для меня. Хотя переход на этот пакет может быть для вас излишним, в долгосрочной перспективе это может стоить проблем, потому что он также устраняет множество проблем, с которыми вы столкнетесь всего несколько месяцев спустя.
(+ некоторые дополнительные функции, такие как гибкий поиск по нескольким свойствам)
вот пакет (это расширение Spring Data JPA/Data Rest)
Разве вы не можете обеспечить соблюдение правил безопасности на уровне http?