Spring Security: Советы по управлению GrantedAuthority

Question

У меня есть проблема, когда дело доходит до объектов GrantedAuthority в приложении Spring Security. Я ищу хороший способ справиться с вещами. Прежде всего, я пытаюсь описать свою озабоченность, если есть какие-то фактические ошибки, не стесняйтесь указывать на них, я буду только благодарен.

Spring Security использует экземпляры GrantedAuthority, чтобы действовать как токены авторизации в разных частях приложения.

По умолчанию GrantedAuthority может представлять себя как String. Когда методы, закрепленные с помощью @Secured («ROLE_NAME») или URL, защищены с использованием конфигурации Spring XML или когда HttpServletRequest запрос проверяется программно, как в если (request.isUserInRole («ROLE_NAME»)) {..} это всегда строка, которую вы используете, чтобы указать полномочия, на которые установлен флажок.

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

Каков наилучший способ для вас, когда дело касается обработки объектов GrantedAuthority в приложении Spring Security? Какие плюсы и минусы имеют ваше решение?

Answer 1

Я не вижу здесь большой проблемы. Для GrantedAuthority очень маловероятно изменить ключ. Просто не называйте роли ROLE_A.

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

Answer 2

Весной и другими системами (особенно для динамических языков) используется «Конвенция по конфигурации». Если бы вы сами могли сами определять имена ролей, вы легко обнаружите, что нужны гораздо больше строк кода.

Так что придерживаться конвенции. Всегда используйте 3 следующие роли: ROLE_ANONYMOUS, ROLE_ADMIN и ROLE_USER. Если вам нужен другой, назовите его соответствующим образом и используйте его во всех случаях. Документация важна.

Также тестируется модульное тестирование. Это помогает вам в случаях, когда ошибка не улавливается компилятором.

Answer 3

Прежде всего, если возможно, выполняйте свои проверки только в определенном месте приложения (например, HTTP-перехватчик в начале запроса) и используя только один из указанных подходов. Это хорошая практика, так как вы сможете авторитетно узнать, когда пользователь станет авторизованным.

Если это невозможно, используйте перечисления для имен ролей и сравните их только с перечислениями. Поэтому, если вы хотите найти все приложения в приложении, это простой поиск.