В этой статье мы покажем, как настроить страницу отказа в доступе в проекте Spring Security .
Этого можно добиться либо с помощью конфигурации Spring Security, либо с помощью конфигурации веб-приложения в файле web.xml .
В остальных разделах мы более подробно рассмотрим каждый из этих вариантов.
React — это основанная на компонентах библиотека JavaScript, созданная Facebook. С React мы можем легко создавать сложные веб-приложения. В этой статье мы собираемся заставить Spring Security работать вместе со страницей входа React.
Мы воспользуемся преимуществами существующих конфигураций Spring Security из предыдущих примеров. Итак, мы будем опираться на предыдущую статью о создании формы входа с помощью Spring Security .
Во-первых, давайте воспользуемся инструментом командной строки create-react-app для создания приложения , выполнив команду « create-react-app react» .
В этой статье основное внимание будет уделено тому, как перенаправить пользователя обратно на первоначально запрошенный URL-адрес после того, как он войдет в систему .
Ранее мы видели, как перенаправлять на разные страницы после входа в систему с помощью Spring Security для разных типов пользователей, и рассматривали различные типы перенаправлений с помощью Spring MVC .
Статья основана на учебнике Spring Security Login .
В этом руководстве мы разберемся с основами протокола аутентификации Kerberos. Мы также рассмотрим потребность в SPNEGO в связи с Kerberos.
Наконец, мы увидим, как использовать расширение Spring Security Kerberos для создания приложений с поддержкой Kerberos с помощью SPNEGO.
Прежде чем мы продолжим, стоит отметить, что в этом руководстве будет представлено много новых терминов для тех, кто не знаком с этой областью. Следовательно, мы потратим некоторое время впереди, чтобы прикрыть территорию.
В этой быстрой статье мы сосредоточимся на том, как программно установить аутентифицированного пользователя в Spring Security и Spring MVC.
Проще говоря, Spring Security хранит основную информацию о каждом аутентифицированном пользователе в ThreadLocal , представленном в виде объекта аутентификации .
Чтобы создать и установить этот объект аутентификации , нам нужно использовать тот же подход, который Spring Security обычно использует для создания объекта стандартной аутентификации.
Для оптимизации сети некоторые веб-сайты позволяют браузерам кэшировать ресурсы, такие как CSS или JS, в локальном хранилище. Это позволяет браузерам сохранять сетевое обращение для каждого запроса.
Таким образом, кэширование ресурсов жизненно важно для сокращения времени загрузки веб-страниц. Не менее важно очищать кэшированные данные, если они не требуются. Например, если пользователь выходит из веб-сайта, браузеры должны удалить все данные сеанса из кеша.
Есть две основные проблемы с кэшированием данных браузерами дольше, чем требуется:
В этом руководстве мы увидим, как HTTP -заголовок ответа Clear-Site-Data помогает веб-сайтам очищать локально сохраненные данные из браузеров.
Фреймворк Spring Security обеспечивает очень гибкую и мощную поддержку аутентификации . Наряду с идентификацией пользователя мы обычно хотим обрабатывать события выхода пользователя из системы и, в некоторых случаях, добавлять некое пользовательское поведение выхода из системы. Одним из таких вариантов использования может быть аннулирование пользовательского кеша или закрытие аутентифицированных сеансов.
Именно для этой цели Spring предоставляет интерфейс LogoutHandler , и в этом руководстве мы рассмотрим, как реализовать собственный обработчик выхода из системы.
Каждое веб-приложение, в котором пользователи входят в систему, должно когда-нибудь выйти из системы. Обработчики Spring Security обычно контролируют процесс выхода из системы . По сути, у нас есть два способа обработки выхода из системы. Как мы увидим, один из них реализует интерфейс LogoutHandler .
В большинстве случаев при защите веб-приложения Spring или REST API инструментов, предоставляемых Spring Security, более чем достаточно, но иногда мы ищем более конкретное поведение.
В этом руководстве мы напишем собственный AccessDecisionVoter и покажем, как его можно использовать для абстрагирования логики авторизации веб-приложения и отделения ее от бизнес-логики приложения.
Чтобы продемонстрировать, как работает AccessDecisionVoter , мы реализуем сценарий с двумя типами пользователей, ПОЛЬЗОВАТЕЛЬ и АДМИНИСТР, в котором ПОЛЬЗОВАТЕЛЬ может получить доступ к системе только в четные минуты, в то время как АДМИНИСТРАТОР всегда будет иметь доступ.
В этой быстрой статье мы объясним тонкую, но существенную разницу между ролью и GrantedAuthority в Spring Security `` . Подробнее о ролях и полномочиях читайте в статье здесь .
Предоставленные полномочияВ Spring Security мы можем думать о каждом GrantedAuthority как об отдельной привилегии . Примеры могут включать READ_AUTHORITY , WRITE_PRIVILEGE или даже CAN_EXECUTE_AS_ROOT . Важно понимать, что имя является произвольным .
В этом руководстве мы создадим страницу входа с использованием Spring Security с помощью:
Пример приложения, которое мы собираемся здесь обсудить, состоит из клиентского приложения, которое взаимодействует со службой REST и защищено базовой HTTP-аутентификацией.