Spring Security: нужен совет о том, как обращаться с GrantedAuthority

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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