Post original em: https://twitter.com/masoxi22/status/1681136803112181760
Este aqui deve ser o matcher mais importante do Spring Security.
Qualquer erro que acontece dentro da aplicação que não é tratado redireciona o usuário para a URL do /error.
Para isso fiz uma simulação e analisei o stack trace. Bora dar uma olhada?
Aqui eu simulei um erro de adição de valores com índices duplicados. Se este erro não for devidamente tratado, o servlet retorna um erro 500, porém, como estamos utilizando o Spring, este erro é tratado pelo próprio container.
Neste caso, ocorre um processamento do erro, utilizando como location o /error. Porém, como também estamos usando Spring Security, o framework irá passar o request pelo SecurityFilterChain, o que requer que ele esteja listado nos matchers.
Se caso eu não instruir a minha aplicação a permitir as requests para /error, então o Spring Security irá jogar um AccessDeniedException. Este AccessDeniedException será capturado pelo ExceptionTranslationFilter que irá me retornar um erro 401 ao invés de 500.
Por que é importante então eu permitir requests para /error? Para não retornar erros errôneos da minha API, principalmente quando estou em dev, testando a aplicação.
Outro workaround seria desabilitar o errorHandling, porém ele desativa o errorHandling do spring security.
Minha preferência pessoal é permitir qualquer request para /error, mas este endpoint tem um comportamento bem curioso.
Mas isso é para um outro fio!
Top comments (0)