Olá, Gabriel. Como vai?
Muito obrigado por compartilhar essa atualização com a comunidade! Esse é um dos tópicos que mais gera dúvidas para quem está estudando segurança com o Spring Boot 3, e o seu post é de enorme utilidade para os outros alunos não ficarem travados.
A sua percepção foi cirúrgica. Nas versões anteriores do Spring Security (como a versão 5), o ecossistema utilizava o padrão de projeto Fluent Builder, onde encadeávamos os métodos com .and(). A partir do Spring Security 6 (adotado pelo Spring Boot 3), a equipe da Spring mudou radicalmente a assinatura dos métodos para adotar expressões lambda e Method References (AbstractHttpConfigurer::disable), tornando o código mais limpo e legível.
Para agregar ainda mais valor ao seu tópico e ajudar os alunos a entenderem o que mudou por trás dos panos, separei uma breve explicação de cada bloco que você atualizou:
1. O fim do método .and()
Nas versões antigas, o método .and() servia como um conector para "voltar" ao objeto principal e configurar outra funcionalidade. Com as expressões lambda, cada configuração fica encapsulada em seu próprio escopo. O próprio Spring sabe onde começa e termina a configuração do sessionManagement, eliminando a necessidade do .and().
2. Configurando o CSRF e Session Management
O seu código aplicou a nova convenção de forma perfeita. No caso do CSRF, você utilizou o Method Reference:
.csrf(AbstractHttpConfigurer::disable)
Que é uma forma enxuta de escrever a lambda padrão: .csrf(csrf -> csrf.disable()). Ambas estão corretas e são aceitas pelo Spring Boot 3!
3. A importância do authorizeHttpRequests
Notou que no seu código atualizado você adicionou esse trecho que não estava no código antigo da aula?
.authorizeHttpRequests(authorize -> authorize
.anyRequest().permitAll()
)
- Por que isso é necessário agora? A partir do Spring Boot 3, o Spring Security adotou uma postura mais rígida. Se você configurar o filtro de segurança mas não disser explicitamente quais requisições estão autorizadas ou bloqueadas, o sistema pode barrar todas as suas rotas por padrão ou apresentar comportamentos inesperados. Ao colocar o
.anyRequest().permitAll(), você diz ao Spring: "Por enquanto, configure o filtro como Stateless, mas permita que as requisições passem sem autenticação".
Isso é excelente para testar o ambiente antes de criar os controladores de Login e JWT!
Parabéns pela iniciativa de pesquisar a documentação oficial, corrigir o código e postar a solução prontinha aqui no fórum. Continue com essa postura colaborativa!
Espero que possa ter lhe ajudado!
