Spring Boot e Teste: Profiles, Testes e Deploy | Alura Cursos Online
Primeiras aulas do curso Spring Boot e Teste: Profiles, Testes e Deploy
Spring Boot e Teste: Profiles, Testes e Deploy
Mais segurança - Introdução
Olá, pessoal, seja muito bem vindo, muito bem-vinda ao terceiro treinamento de Spring Boot da Alura. Meu nome é Rodrigo Ferreira e eu vou continuar com vocês nessa jornada de exploração ao framework Spring Boot.
Nós já tínhamos dois treinamentos na Alura sobre o Spring Boot, e agora temos o terceiro, a parte três da nossa construção da API Rest do fórum da Alura utilizando esse framework Spring Boot.
Qual é o objetivo desse curso? Ainda vamos continuar utilizando aquela mesma aplicação, o fórum da Alura, só que nos dois outros cursos, apesar de serem completos, ficaram faltando algumas coisas que daria para deixar mais interessante ainda nossa API.
A primeira coisa que faremos nesse curso é justamente atualizar o projeto. Então os dois primeiros cursos de Spring Boot foram gravados em 2019 e o Spring estava na versão 2.1.4. E esse terceiro curso está sendo gravado em 2020, então passou muito tempo e o Spring continua sendo evoluído, muitas outras versões foram surgindo.
Então vamos aprender como atualizar um projeto com Spring Boot, como avaliar os impactos dessa atualização e corrigir quaisquer problemas que possam acontecer.
Então uma coisa boa, atualizar a versão do Spring Boot no projeto, ver os impactos e ficar trabalhando sempre com as últimas versões para pegar as melhorias, correções de bugs e de falhas de segurança.
Outra coisa que não vimos nos outros cursos foi a parte de testes automatizados. Isso é algo extremamente importante, porque muitos times de desenvolvimento adotam essa prática de escrever testes automatizados.
Então nesse terceiro curso vamos aprender como escrever testes automatizados dos componentes utilizando Spring Boot. Então veremos como fazer testes dos Repositories, dos Controllers para garantir que nossa aplicação está funcionando, e se alguma mudança for feita detectarmos rapidamente.
Então teste automatizado foi outra coisa que não deu para ver os outros cursos e que veremos nesse terceiro curso.
A questão de Profiles também, como utilizar ambientes, separar configurações do ambiente de desenvolvimento, do ambiente de produção, como funciona isso no Spring Boot, que já tem um mecanismo próprio para trabalharmos com essas diferenças de ambientes. Então veremos como fazer isso nesse terceiro curso.
A parte de Build e de Deploy: terminamos a parte de API, mas ficou faltando aprender sobre o Deploy, como gerar o Build desse projeto. Nesse curso vamos aprender como gerar o Build do .jar ou do tradicional .war e como fazer para simular um Deploy dessa aplicação.
Inclusive vamos ver depois como fazer para utilizar o Docker, que é uma tecnologia de contêineres que está bastante popular. Então vamos aprender a utilizar o Docker na aplicação com Spring Boot, adicionar o Docker na aplicação com Spring Boot, ver quais são as configurações e como funciona tudo isso.
Então essas são algumas das novidades que veremos nesse terceiro curso que ficou faltando nos outros cursos e que são coisas importantes que deixam a nossa aplicação um pouco mais completa, e assim você fica sabendo como lidar com essas outras tecnologias, com essas outras abordagens que ficaram faltando nos outros cursos.
Então espero que vocês gostem desse treinamento. Vejo vocês na primeira aula. Um abraço e até lá.
Mais segurança - Atualizando o Spring Boot
Olá, pessoal, bem-vindos de volta a mais um treinamento de Spring Boot na Alura. Na aula de hoje, nessa primeira aula, vamos começar a trabalhar no projeto.
E nesse terceiro curso de Spring Boot vamos aprender algumas coisas a mais que ficaram faltando nos outros dois treinamento.
E para começar, a primeira coisa que precisamos fazer é atualizar a versão do Spring Boot no nosso projeto.
Nós gravamos os dois primeiros cursos de Spring Boot na Alura mais ou menos em junho de 2019. Naquela época o Spring Boot estava na versão 2.1.4. Não sei se vocês lembram, nós criamos o projeto no site do Spring Initializr e a versão que tinha a estável, era a 2.1.4.
Mas estamos gravando esse terceiro curso de Spring Boot em julho de 2020, e muita coisa mudou desde então. O projeto do Spring não ficou parado no tempo. A galera que faz a manutenção, que está evoluindo o projeto desenvolveu novas funcionalidades, novos recursos, corrigiram bugs. E muitas outras versões foram surgindo.
Para não trabalharmos num projeto obsoleto, numa versão muito anterior, a primeira coisa que faremos é atualizar a versão do Spring Boot no nosso projeto. Se entrarmos no site do Spring Initializr, em "start.spring.io", veremos que a versão que eles sugerem se você for criar um projeto do zero, a versão que já vem marcada por padrão é a 2.3.1.
A versão atual, no momento de gravação do vídeo desse terceiro curso de Spring Boot, é a 2.3.1. Então estamos muito desatualizados, nosso projeto está na versão 2.1.4. Então a primeira coisa que faremos é atualizar o Spring Boot no projeto.
Agora estou no Eclipse, já estou com meu projeto importado. É o mesmo projeto que foi finalizado no segundo curso, o fórum da Alura com todas as funcionalidades que vimos no segundo curso do Spring Boot.
Lembra que estamos usando o Maven, então precisamos abrir o pom.xml. E lembra que tem aquela tag <parent>, e está ali a versão 2.1.4.
<groupId>br.com.alura</groupId>
<artifactId>forum</artifactId>
E temos que trocar para 2.3.1. Vou trocar e salvar. Se você fizer isso pela primeira vez no seu computador o Maven vai detectar que você trocou a versão do projeto, vai baixar todas as novas dependências na internet, então pode ser que demore um pouco. É só você esperar que ele mostra o progresso no canto inferior direito da tela. No meu caso eu já tinha feito isso antes, então foi um pouco mais rápido.
Nós estamos atualizando o projeto, na teoria não deveria mudar muita coisa, vamos aproveitar os novos recursos. Mas na prática, quem já trabalhou com desenvolvimento de software já deve ter passado por isso, toda vez que você vai atualizar uma biblioteca em um projeto você tem que tomar muito cuidado.
Porque você pode correr um risco de atualizar uma biblioteca, sendo que essa nova versão pode ter gerado uma quebra de compatibilidade. Pode ter alguma funcionalidade, alguma classe, algum método que mudou a assinatura, foi apagado, enfim. Então isso pode gerar um erro de compilação ou uma mudança no comportamento de determinada funcionalidade.
Então para fazer essa mudança você tem que tomar muito cuidado, você não pode simplesmente chegar e atualizar. Você tem que pesquisar e fazer isso com calma para ver se não vai gerar problemas.
Inclusive, no nosso caso, você pode ver que tem um "X" vermelho no projeto, na parte esquerda da tela. Então no "src/main/java", em "br.com.alura.forum", no pacote "controller" deu erro de compilação. Acabamos de ter um problema no nosso projeto.
Vamos abrir, por exemplo, a classe "TopicosController", que é onde está tendo um erro de compilação. E o problema está justamente no nosso método cadastrar. Ele recebe aquele TopicoForm, aquele objeto seguindo o padrão DTO e a anotação @Valid, do BIN Validation.
Ele está falando que não encontrou a anotação @Valid. Então se formos ao início da classe e expandirmos os imports, veremos que o pacote dela está correto, é javax.validation.Valid;.
Além disso, no pacote "form", os nossos forms estão com problema também. Todas as anotações do BIN Validation estão com erro de compilação. E ele está dizendo que não encontrou essas classes. E esse é justamente o problema que aconteceu com o nosso projeto.
Na versão 2.3.0 do Spring Boot eles fizeram uma mudança e o BIN Validation não vem mais por padrão no projeto. Se você se você quiser utilizar o BIN Validation no seu projeto você tem que adicionar de maneira separada a dependência do BIN Validation.
Antes ela vinha automática. Só de você importar o módulo web já vinha embutido o BIN Validation. Agora não vem mais.
Inclusive, deixa eu mostrar pra vocês, eu entrei no site do GitHub, na página do projeto do Spring Boot, "github.com/spring-projects/spring-boot", que é o código fonte do Spring Boot; o Spring Boot é uma biblioteca de código fonte aberto.
Então ele tem todo o código fonte do Spring Boot, tem embaixo uma documentação explicando o que é o projeto, mas eu quero que vocês subam e deem uma olhada na lateral direita, na parte de Releases.
Ele está mostrando que a última versão, a última release é a 2.3.1. Vamos clicar nela. No caso do Spring Boot, sempre que você quiser atualizar para uma versão, eu recomendo que você entre no site do projeto, veja as notas do release e veja o que mudou.
Então ele fala quais são as novas funcionalidades, quais são os bugs que foram corrigidos, documentação que foi atualizada, ele te fala tudo que mudou.
Em cima da parte "New Features", logo abaixo do número da versão, se tivesse algum manual de incompatibilidades apareceria um link. Não apareceu porque na verdade vamos usar a versão 2.3.1, mas foi na 2.3.0 que teve essa mudança.
Então na barra de endereço vou trocar de 2.3.1 para 2.3.0. E já na versão 2.3.0, ele diz "para fazer o upgrade leia essas instruções". Ao clicar ele vai descrever as mudanças caso você esteja fazendo upgrade da versão 2.2. Ele explica o que mandou, e ele fala que validação não é mais inclusa no módulo web.
Caso você queira utilizar validação, você tem que adicionar essa dependência descrita. Foi isso que aconteceu no nosso projeto.
<artifactId>spring-boot-starter-validation<|artifactId>
Vou dar um "Ctrl + C" nessa dependência, vou voltar no Eclipse, no pom.xml, e na parte de dependências vou colar. Dou um "Ctrl + Shift + F" para formatar. E agora eu tenho um módulo de validação.
Antes já vinha embutido por padrão do módulo web e agora você tem que adicionar manualmente. Então vou salvar, ele vai recompilar o projeto. Vou clicar com o botão direito no projeto, escolher "Maven > Update Project", só para ele atualizar.
E perceba que já pararam os erros de compilação. Então cuidado, sempre que você atualizar uma biblioteca no projeto dê uma analisada se não teve nenhum impacto.
Então a ideia era só atualizarmos o Spring Boot para pegar uma versão mais recente, mais atual e ver quais foram os impactos; e eu queria mostrar para vocês onde que você consegue pesquisar, no caso do Spring Boot é no GitHub mesmo. Sempre que tem uma nova release eles publicam essas notas com as mudanças que foram introduzidas nesta nova versão.
Então é importante você ler para ver se não teve nenhum impacto. Eu até coloquei como uma curiosidade a questão de versionamento de software. Geralmente no versionamento de software tem esses números, como a versão 2.3.1, ou 2.3.2. O que significam esses números?
O primeiro número é o principal, chamado de Major. É o número que representa uma mudança maior no projeto. Então sempre que tem uma mudança no número, como de 1.0 para 2.0, é uma mudança drástica que pode ter quebra de compatibilidade.
O segundo número é o Minor. É quando vai de 2.2 para 2.3, por exemplo. Eu ainda estou na versão 2, só que saiu da 2.2 para a 2.3. Pode ter mudanças que quebrem. Geralmente não vai quebrar a compatibilidade, serão novas funcionalidades, mas às vezes acontece.
E o último número é o indicador do Patch. É uma mudança de uma versão 2.3.0 para 2.3.1, por exemplo. Então mudou só o último número, que é o número de Patch. Nesse caso é bem raro ter quebra de compatibilidade.
Quando muda esse último número é só correção de bug, algumas correções de segurança, coisa pontual. Não foram novas funcionalidades, nada que vai causar um impacto muito grande.
Como no nosso caso saímos da versão 2.1 para a 2.3, nós pulamos 2 Minor versions. Então foi um salto muito grande, no caso acabou quebrando compatibilidade porque o pessoal do Spring Boot deixou opcional aquela parte de validação.
Afinal, nem todo projeto tem validação. É bem comum de ter, mas vai que um dia não tenha essa obrigatoriedade, então eles deixaram de fora.
Então por hoje esse era o objetivo da nossa aula, ver como atualizar o projeto, ver essas questões de versionamento de software e ver a página do GitHub para acompanhar essas mudanças e ver quais são os impactos.
Na próxima aula começaremos de fato a mexer no projeto e implementar as novas funcionalidades que veremos no terceiro curso. Espero vocês no próximo vídeo. Um abraço e até lá.
Mais segurança - Autorização baseada em Roles
Olá, bem-vindos de volta ao treinamento de Spring Boot. Na última aula aprendemos a atualizar a versão do Spring Boot do nosso projeto e atualizamos da versão 2.1.4 para a 2.3.1. E agora o projeto está atualizado, está tudo funcionando, compilando corretamente.
Nessa aula vamos aprender um pouco mais sobre segurança, sobre o conceito de autorização que nós não vimos no último curso. Não sei se vocês lembram, mas no segundo curso de Spring Boot aprendemos como colocar segurança na aplicação, para cuidar da parte de autenticação e autorização. No pom.xml, se descermos um pouco podemos ver que tem a dependência do Spring Security.
Nós tivemos que colocar essa dependência do Spring Security, também tivemos que criar a classe SecurityConfigurations, onde fizemos todo o processo de configuração de como funcionaria nossa autenticação, e a parte de autorização que acabamos deixando de lado.
Tivemos que criar a classe Usuario e a classe Perfil, para representar o perfil do usuário. Fizemos todo aquele mecanismo de autenticação, no começo fazendo autenticação tradicional, com sessão, que era aquela autenticação utilizada em aplicações web tradicionais.
Mas depois vimos que não era uma boa prática essa autenticação tradicional com sessão em uma API Rest. É justamente o que desenvolvemos no curso, uma API Rest do fórum da Alura.
Então migramos todo o código para utilizar aquele esquema de autenticação stateless. Então usamos a biblioteca JJWT para fazer a geração de Tokens.
Quando o usuário quer acessar o fórum da Alura, quer se autenticar, primeiro ele entra no endereço/auth, aquele endpoint para se autenticar; passa o e-mail e a senha. Se tiver os dados corretos nós devolvemos um Token e a aplicação frontend dessa pessoa tem que guardar esse Token e nas próximas aquisições sempre enviar esse Token como um cabeçalho.
E tivemos que criar aquela classe que faz toda essa lógica de recuperar esse Token do cabeçalho, validar, forçar uma autenticação durante essa requisição e liberar a requisição para o usuário.
Então fizemos todo esse trabalho utilizando Spring Security e a biblioteca para gerar Tokens JJWT.
Só que em todo esse processo nós focamos basicamente na parte de autenticação. Eu queria restringir algumas URL's. Na Security Configurations, tem algumas URL's que estão públicas para listar os tópicos, para detalhar um tópico, para se autenticar. Mas todo o resto está restrito. Só que a minha preocupação era toda nessa parte de autenticação.
Então antes de executar a lógica, a regra de negócio, eu precisava verificar se o usuário estava logado, se ele tinha o Token, se estava autentificado. E deixamos de fora a parte de autorização.
E nem sempre numa aplicação basta a pessoa estar logada. Às vezes têm regras de negócio que envolvem perfil de acesso. Você está autentificado, mas você tem permissão para executar essa ação no sistema? Então foi isso que ficou faltando e é justamente o que veremos na aula de hoje.
Então o que vamos fazer aqui no caso do nosso projeto? Eu vou abrir a classe TopicosController, que é onde estão todas funcionalidades referentes a tópicos. E a última que fizemos é aquela parte de excluir, de remover.
Então uma das funcionalidades é que eu queria permitir que o usuário pudesse excluir um determinado tópico. Só que do modo como está implemetado nós não fazemos nenhuma verificação de autorização. Basta que a pessoa esteja autenticada no sistema para ela conseguir excluir um tópico.
Vamos imaginar que a regra não é desse jeito, vamos pensar que a regra vai funcionar da seguinte maneira: só pode excluir um tópico se a pessoa tiver o perfil de moderador.
Então imagina que tem dois perfis no fórum da Alura: tem o perfil de aluno, que é qualquer aluno que vai cadastrar os tópicos, responder e ajudar as outras pessoas; e tem o perfil de moderador, que é aquela pessoa que controla, que organiza e ajuda os alunos que estão com dificuldades na plataforma.
Então vamos considerar que nem o próprio aluno pode excluir o tópico. Ele pode marcar como solucionado, ou ele pode fechar o tópico para não receber mais perguntas. Mas vamos considerar que ele não tem permissão para excluir. Só quem tem perfil de moderador pode fazer isso.
Para implementar essa regra, na verdade não vamos mexer no Controller, não precisamos fazer um if else. Nós fazemos isso direto na classe SecurityConfigurations, no mesmo local onde configuramos as URL's do projeto.
Então vamos adicionar mais uma URL. Acima estão todas as URL's que estão públicas. Abaixo de .anyRequest().authenticated() tem que estar autenticado. Mas não apenas isso tem que ter o perfil de moderador no caso da exclusão.
//Configuracoes de autorizacao
.antMatchers(HttpMethod.GET, "/topicos").permitAll()
.antMatchers(HttpMethod.GET, "/topicos/*").permitAll()
.antMatchers(HttpMethod.GET, "/actuator/**").permitAll()
.and().addFilterBefore(new AutenticacaoViaTokenFilter(tokenService, usuarioRepository), UsernamePasswordAuthenticationFilter.class);
Eu vou copiar a última linha de URL, vou colar logo abaixo e modificar para: .antMatchers(HttpMethod.DELETE, "/topicos/*") . A requisição é DELETE, que configuramos no Controller e é /tópicos/ seguida de alguma coisa, que no caso é o id.
.antMatchers(HttpMethod.DELETE, "/topicos/*").hasRole("MODERADOR")
Se olharmos no TopicosController é @DeleteMapping("/{id}"). Então eu quero configurar isso.
Só que na verdade não é permitAll, senão eu estou liberando. Para restringir o perfil existe outro método, chamado hasRole. E dentro eu passo qual é o Role, qual é o perfil do usuário.
Então só pode executar uma requisição do tipo de DELETE para o endereço/topicos/* se tiver o perfil que eu vou colocar o nome. Você pode chamar de qualquer coisa, eu vou chamar de moderador. E pronto: .antMatchers(HttpMethod.DELETE, "/topicos/*").hasRole("MODERADOR").
Só isso, não precisa fazer mais nada. Então o Controller nem vai ver que tem essa regra. Na verdade, o Spring Security faz esse controle para nós.
Quando chamarmos o endereço @DeleteMapping("/{id}"), o Spring verifica o perfil da pessoa que está logada. Se for moderador, então ele entra e executa linha por linha. Se não for moderador ele nem entra, ele devolve um 403, um forbidden como resposta. Então isso deixa o nosso código do Controller bem limpo.
E agora já podemos testar. Porém, temos um problema: nós não tínhamos essa questão de perfil no projeto. Não sei se vocês lembram, eu vou abrir aquele arquivo "data.sql", onde tem alguns inserts; toda vez que rodamos o projeto, o Hibernate faz esses inserts no nosso banco de dados, o H2.
Veja que só temos um usuário, e não tem esse negócio de perfil. Então para fazer esse teste eu vou copiar a primeira linha e vou criar outro usuário, mas com o nome de Moderador, o e-mail vai ser `moderador@email.come a senha eu vou deixar a mesma do aluno, que é123456`.
Só que não é só isso, eu estou criando o usuário, mas e o perfil? Qual é o perfil do aluno e qual é o perfil desse segundo usuário? Lembra que além da classe Usuario nós criamos uma classe chamada Perfil, que é uma entidade da JPA. Então tem uma tabela de perfil, nós só não estávamos utilizando; essa tabela estava vazia, sem nenhum registro.
Agora precisamos utilizar essa tabela. Então vou colocar mais um insert abaixo do que acabamos de fazer: INSERT INTO PERFIL, vou inserir um registro na tabela de perfil; só tem duas colunas, que é o id e o nome, então INSERT INTO PERFIL(id, nome) VALUES().
O primeiro perfil vai ser o aluno, e o Spring Security tem um padrão, em que o nome do perfil tem que ter o prefixo ROLE_. Então INSERT INTO PERFIL(id, nome) VALUES(1, 'ROLE_ALUNO');.
E além do aluno eu vou ter outro perfil que vai ser o Moderador, então INSERT INTO PERFIL(id, nome) VALUES(2, 'ROLE_MODERADOR');.
Pronto, agora tenho dois perfis no sistema, o ROLE_ALUNO e o ROLE_MODERADOR.
Porém, agora eu preciso associar com esses dois usuários. Essa associação é feita numa tabela de JOIN. Então além da tabela usuário e da tabela perfil, tem uma tabela chamada USUARIO_PERFIS. É "perfis" porque esse é o nome do atributo na classe Usuário.
Essa tabela tem duas colunas, a usuario_id e a perfis_id , então fica INSERT INTO USUARIO_PERFIS(usuario_id, perfis_id);.
E depois colocamos os valores: eu quero jogar no usuário de id 1, que é o aluno, o perfil 1, então INSERT INTO USUARIO_PERFIS(usuario_id, perfis_id) VALUES(1, 1);.
Vou duplicar essa linha e agora eu quero jogar no usuário de id 2, que é o moderador, o perfil de moderador, então INSERT INTO USUARIO_PERFIS(usuario_id, perfis_id) VALUES(2, 2);.
Pronto, com isso eu já consigo configurar dois usuários no sistema, sendo um aluno e um moderador, cada um com seu respectivo perfil.
Salvei, vou rodar o projeto. Ele vai inicializar, vai carregar. A parte de código já está pronta, era só isso; era só colocar aquele hasRole no SecurityConfigurations, e o data.sql era só para popular o banco de dados.
Não precisa mexer em mais nada, é bem simples fazer o controle de autorização: é a URL, hasRole e qual é o perfil que você quer restringir para essa URL.
Para testar vamos utilizar o Postman. Não sei se vocês lembram, mas estávamos utilizando o Postman no outro curso para simular requisições HTTP para nossa API.
Então eu vou fazer uma requisição GET: http://locahost:8080/topicos/1. Eu quero detalhar o tópico de id 1, só para recuperarmos os dados e verificar quais são as informações desse tópico. Ele está inicializando.
Isso seria só para vermos que todos os tópicos que eu inseri no data.sql estão cadastrados, têm 3 registros. Até vou mudar o expoente, vou chamar o http://locahost:8080/topicos, porque eu quero ver todos os registros.
Ele deu um problema por causa do actuator. Eu não subi o projeto do actuator, não vamos mexer nele.
Vou ver se não digitei nada errado. Digitei errado, o correto fica http://localhost:8080/topicos. E estão lá os 3 registros.
E agora eu quero testar o excluir, foi no excluir que fizemos a regra. Vou abrir uma nova aba no Postman, vou copiar o endereço http://localhost:8080/topicos/1 e vou mudar o método de GET para DELETE.
Vamos tentar simular dessa maneira, vou mandar um DELETE para esse endereço. E apareceu "forbidden", porque lembrem que o endereço de listar os tópicos está público, mas o de excluir está privado. Você precisa estar autentificado no sistema.
Eu vou abrir uma nova aba e colocar o endereço como http://localhost:8080/auth, que é o endereço para autenticarmos. Mas para autenticar, a requisição é do tipo POST. Na aba "Headers", tem que selecionar "Content-Type" no campo KEY e "application/json" no campo VALUE, para dizermos para a API que estamos mandando dados no formato JSON.
E no menu "Body" vou selecionar raw e vou passar direto o JSON com os dados. Para fazer autenticação tínhamos que mandar o campo e-mail, e para testar eu vou logar com `aluno@email.com, então fica"email":"aluno@email.com", "senha":"123456"`.
Vou disparar essa requisição. Ele deveria processar com sucesso e me devolver aquele Bearer Token, que é gerado pelo JJWT. E ele gerou.
Vou copiar o Token de autenticação. Agora eu vou voltar na requisição de deletar e para mandar o Token lembra que ele é um cabeçalho, ele vem na aba "Headers".
Ou você pode vir na aba "Authorization", que é mais fácil, escolher o Bearer Token e colar no campo ao lado. Vou disparar a requisição de excluir agora e deu "forbidden", porque eu estou logado, mas eu loguei como aluno, e o aluno não tem permissão. Então funcionou, ele não me deixou excluir o registro.
Agora na aba "Body" eu vou trocar para moderador: "email":"moderador@email.com". Vou me autenticar como moderador. Vai disparar a requisição e vai vir outro Token, com o final diferente.
Vou copiar esse Token, na aba "Authorization" vou apagar o que já tinha e substituir. Agora é para dar 200, é para dar que a requisição foi processada com sucesso. E voltou o HTTP status para 200.
Só para garantir vou listar de novo os registros e veio o registro de id 2 o registro de id 3. Então ele excluiu de fato o registro de id 1.
E para fazer a parte de autorização baseado em perfil, é basicamente você vir no Security Configuration, configurar qual é a URL e qual é o perfil que tem permissão para disparar. Não basta apenas estar autenticado, tem que também ter esse perfil.
Um detalhe importante é que aqui no SecurityConfiguration nós não colocamos aquele ROLE_. O Spring já coloca isso automaticamente.
Então no banco de dados o perfil tem que estar ROLE_ALUNO, ROLE_MODERADOR. Mas no hasRole você só passa o nome do Role, o Spring já coloca automaticamente o prefixo ROLE_.
E com isso fechamos a aula de hoje. Nós vimos que é bem simples e tranquilo fazer um controle de autorização baseado em perfil no Spring. Lembrando de popular o seu banco de dados, a tabela de perfis e a tabela de JOIN entre o usuário e o perfil para o Spring saber quem tem cada tipo de perfil.
Sobre o curso Spring Boot e Teste: Profiles, Testes e Deploy
O curso Spring Boot e Teste: Profiles, Testes e Deploy possui 168 minutos de vídeos, em um total de 47 atividades. Gostou? Conheça nossos outros cursos de Java em Programação, ou leia nossos artigos de Programação.