Form login, роли

Form login — классическая аутентификация через форму логина с куки-сессией, как на большинстве обычных сайтов (в отличие от JWT-токенов, см. тему «JWT и OAuth2»).

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .formLogin(form -> form
            .loginPage("/login")
            .defaultSuccessUrl("/dashboard"))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/login", "/register").permitAll()
            .anyRequest().authenticated());
    return http.build();
}

После успешного логина Spring Security создаёт сессию на сервере и отправляет браузеру куки с её id — браузер автоматически отправляет эту куки при каждом следующем запросе, и сервер по ней узнаёт пользователя.

Копнуть глубже

Роли — упрощённый способ управления доступом по группам:

@PreAuthorize("hasRole('ADMIN')")     // только пользователи с ролью ADMIN
void deleteUser(Long id) { ... }

@PreAuthorize("hasAnyRole('ADMIN', 'MODERATOR')")
void banUser(Long id) { ... }

@PreAuthorize проверяет условие до выполнения метода — если условие не выполняется, метод даже не вызывается, сразу возвращается 403 Forbidden. Это ещё один пример AOP (см. тему «Зачем AOP») — проверка прав вынесена из бизнес-логики в аннотацию.

Хранение пароля. Пароли никогда не хранятся в открытом виде — Spring Security по умолчанию использует BCryptPasswordEncoder, который хэширует пароль перед сохранением и проверяет введённый пароль сравнением хэшей, а не самих паролей. Восстановить исходный пароль из хэша невозможно — это намеренное свойство криптографического хэширования.

🎤 Закрыл тему, если можешь объяснить:

• как работает form login и сессионные куки;
• как `@PreAuthorize` проверяет роли и почему пароли хранят хэшированными (если дошёл до 2-го слоя).