Este é um projeto Java usando Quarkus e Maven. Ele foi projetado para validar JWTs (JSON Web Tokens) e inclui várias classes para lidar com diferentes aspectos desse processo.
Para construir e executar este projeto, você precisará ter o seguinte instalado em seu ambiente de desenvolvimento:
-
Java 21 ou superior
Você pode verificar a versão do Java instalada em seu ambiente de desenvolvimento usando o seguinte comando:
java -versionSe você não tiver o Java instalado, ou se a versão instalada não atender aos requisitos, você precisará instalar ou atualizar essa ferramenta.
O SDKMAN é uma ferramenta que permite gerenciar múltiplas versões do Java (e outras ferramentas de desenvolvimento de software) em um único sistema. Para instalar o SDKMAN e usar para instalar o Java, siga os passos abaixo:
-
Abra um terminal
-
Instale o SDKMAN com o seguinte comando:
curl -s "https://get.sdkman.io" | bash
-
Abra uma nova sessão de terminal ou execute o seguinte comando para garantir que o SDKMAN esteja disponível:
source "$HOME/.sdkman/bin/sdkman-init.sh"
-
Instale o Java 21 ou superior com o seguinte comando:
sdk install java 21-graalce
Neste comando, por exemplo, está instalando a versão 21 do GraalVM Community Edition.
Consulte a documentação oficial do SDKMAN para obter mais informações e instruções de instalação.
Para instalar o Java no Windows, você pode baixar o instalador do site oficial do Oracle. Siga os passos abaixo:
-
Acesse o site oficial do Oracle.
-
Clique no botão "Download" para a versão do Java que você deseja instalar.
-
Aceite o acordo de licença.
-
Clique no link para o instalador do Windows para baixar o arquivo de instalação.
-
Execute o arquivo de instalação e siga as instruções na tela para instalar o Java.
Este projeto utiliza o Maven Wrapper, portanto, não é necessário instalar o Maven localmente. O Maven Wrapper é uma excelente opção para projetos que precisam de uma versão específica do Maven (ou para usuários que não querem instalar o Maven em tudo). Ele baixa automaticamente a versão correta do Maven para o seu projeto e a coloca no diretório .mvn.
Para construir o projeto, você pode usar o seguinte comando:
./mvnw clean packagePara executar o projeto, use o seguinte comando:
./mvnw compile quarkus:devEsta é uma interface que define a validação de tokens JWT. Ela contém uma constante JWT_VALIDATION_RULES que é um predicado. Este predicado é uma composição de várias regras de validação que verificam se um JsonObject representando um JWT é válido. As regras verificam se o JsonObject não é nulo, se contém apenas reivindicações suportadas e se cada reivindicação individual é válida. A interface também contém um método privado estático extractClaims(String token) que extrai as reivindicações de um token JWT. Este método divide o token em seções, decodifica a seção de reivindicações e a lê em um JsonObject. O método isValid(String token) usa as JWT_VALIDATION_RULES para testar se um token é válido. Ele faz isso extraindo as reivindicações do token e passando-as para o predicado JWT_VALIDATION_RULES.
Esta é uma enumeração que representa diferentes tipos de reivindicações que podem estar presentes em um JWT. Cada valor de enumeração tem um método isValidClaim(JsonObject claims) que verifica se a reivindicação é válida. Por exemplo, a reivindicação NAME é válida se o valor for uma string que não contém dígitos e cujo comprimento não excede 256 caracteres. A reivindicação ROLE é válida se o valor for uma das funções suportadas. A reivindicação SEED é válida se o valor for um número primo. A enumeração Claim também contém uma enumeração interna Roles que representa os papéis suportados. Além disso, a enumeração Claim contém um método containsOnlySupportedClaims(JsonObject jsonObject) que verifica se um JsonObject contém apenas reivindicações suportadas. Ele faz isso comparando as chaves do JsonObject com os rótulos das reivindicações suportadas.
Esta é uma anotação de validação personalizada que segue a especificação Jakarta Bean Validation que pode ser usada para validar se uma string é um token JWT válido. A validação é realizada pela classe JWTConstraintValidator.
Esta é uma classe que implementa ConstraintValidator da especificação Jakarta Bean Validation e define a lógica de validação para a anotação JWT. Ela usa o método isValid da interface JwtValidator para verificar se uma string é um token JWT válido.
Esta é uma classe que define endpoints REST que seguem a especificação Jakarta RESTful Web Services para validar tokens JWT. Ela tem dois métodos, validate (que usa o JwtValidador como regra de negócio) e validateWithBeanValidation (que usa a anotacão @JWT e a especificação Jakarta Bean Validation por debaixo dos panos, executando a validação antes do método ser executado), que aceitam um token JWT como entrada e retornam uma resposta HTTP indicando se o token é válido.
Esta é uma classe que implementa a interface ExceptionMapper do Jakarta RESTful Web Services. Ela é usada para mapear exceções do tipo ConstraintViolationException para respostas HTTP. Essa exceção é oriunda de validações executadas pela implementação da especificação Jakarta Bean Validation, o Hibernate Validator.
Caso alguma exceção do tipo ConstraintViolationException ocorra, no contexto deste projeto, a exceção será mapeada para uma resposta HTTP com o status BAD_REQUEST. O corpo da resposta é uma string que contém a mensagem de violação de restrição da exceção. Caso ocorra mais violações, esse mapper irá tratar todas as mensagens de violação de restrição da exceção concatenando-as e separado-as por vírgulas.
Esta é uma interface que fornece métodos para criar tokens JWT válidos e inválidos para testes. Ela também fornece um conjunto de cenários de tokens inválidos para testes parametrizados. Além disso, ela contém uma série de métodos estáticos e privados que ajudam a criar tokens JWT com diferentes tipos de reivindicações (claims). Essas reivindicações podem ser válidas ou inválidas, dependendo do cenário de teste.
Estas são classes de teste para a classe JwtValidatorResource. Elas contêm testes para os endpoints v1/jwt/validate e v2/jwt/validate. Os testes verificam se os endpoints retornam os códigos de status HTTP corretos e as respostas corretas para tokens JWT válidos e inválidos.
Para executar os testes do projeto, use o seguinte comando:
./mvnw testO projeto está configurado por padrão expor a documentação da API no endpoint /q/swagger-ui/.
Para utilizá-lo, a aplicação deve estar em execução. Caso não esteja, e queira testar em Dev Mode, sigua o seguinte comando:
./mvnw compile quarkus:devCom isso, você já poderá acessar a documentação da API em http://localhost:8080/q/swagger-ui/ e realizar os testes diretamente pela interface do Swagger.
Para executar os testes utilizando o Insomnia, importe as coleções do Insomnia a partir do arquivo insomnia.yaml. Segue abaixo os passos para realizar a importação:
-
Abra o aplicativo Insomnia.
-
Clique em "Application" no canto superior esquerdo e selecione "Preferences".
-
Na janela de preferências, clique na aba "Data".
-
Clique em "Import Data" e selecione "From File".
-
Navegue até o local do arquivo
insomnia.yamle clique em "Open".
O Insomnia irá importar todas as coleções, ambientes e configurações definidas no arquivo insomnia.yaml.
Garanta que as configurações importadas estão apontando para a host e porta do projeto corretamente. Caso contrário, você precisará ajustar as configurações manualmente.
A configuração atual está apontando para http://localhost:8080, com isso, basta inicializar o projeto no modo Dev Mode e executar as requisições.
Este projeto utiliza o GitHub Actions para implementar um pipeline de Integração Contínua (CI) e Entrega Contínua (CD). Existem dois arquivos de workflow principais localizados no diretório .github/workflows:
Este arquivo define o pipeline de Integração Contínua (CI). Ele é acionado em cada push ou pull request para a branch main, exceto quando os arquivos .adoc são modificados.
O pipeline realiza as seguintes ações:
-
Verifica o código-fonte do repositório.
-
Configura o JDK com a versão especificada na matriz de estratégia.
-
Compila e verifica o projeto com Maven.
O pipeline é configurado para executar em paralelo em várias versões do JDK, conforme especificado na matriz de estratégia.
Este arquivo define o pipeline de Entrega Contínua (CD). Ele é acionado manualmente através do recurso workflow_dispatch do GitHub Actions.
O pipeline realiza as seguintes ações:
-
Verifica o código-fonte do repositório.
-
Configura o JDK com a versão especificada na entrada do workflow.
-
Compila o projeto com Maven.
-
Constrói uma imagem Docker a partir do Dockerfile localizado em
src/main/docker/Dockerfile.jvm. -
Faz login no Docker Hub usando as credenciais armazenadas nos segredos do GitHub.
-
Empurra a imagem Docker para o Docker Hub.
-
Instala o CLI do OpenShift.
-
Faz login no OpenShift (Sandbox for free).
-
Aplica os manifestos específicos.
O pipeline é configurado para executar em uma única versão do JDK, conforme especificado na entrada do workflow.
|
Note
|
Esse passo requer que a imagem do projeto esteja disponível em um repositório de imagens acessível pelo Kubernetes. |
Este projeto é configurado para gerar automaticamente os manifestos de deployment para Kubernetes. Isso é feito através do Quarkus Kubernetes extension, que é capaz de gerar automaticamente os recursos do Kubernetes ou Openshift com base em suas configurações de aplicativo.
Os manifestos gerados automaticamente incluem:
-
Um Deployment para gerenciar a criação e escalonamento de Pods
-
Um Service para fornecer uma maneira consistente de acessar o aplicativo
Os manifestos são gerados durante a fase de compilação do Maven e podem ser encontrados no diretório target/kubernetes.
Para implantar o aplicativo no Kubernetes, você pode usar o comando kubectl apply -f target/kubernetes/kubernetes.yml.
Lembre-se de que você precisa ter o kubectl instalado e configurado para se comunicar com seu cluster Kubernetes. Além disso, você deve ter as permissões necessárias para criar e gerenciar os recursos do Kubernetes no namespace desejado.
Este projeto está configurado para usar o OpenTelemetry para coleta de dados de telemetria, como rastreamento de solicitações e métricas.
Para habilitar o monitoramento com OpenTelemetry, é necessário aplicar os manifestos Kubernetes localizados no diretório src/main/k8s. Estes manifestos configuram os serviços necessários para o funcionamento do OpenTelemetry, como o Jaeger para rastreamento.
Você pode aplicar os manifestos usando o comando kubectl apply -f src/main/k8s.
Lembre-se de que você precisa ter o kubectl instalado e configurado para se comunicar com seu cluster Kubernetes. Além disso, você deve ter as permissões necessárias para criar e gerenciar os recursos do Kubernetes no namespace desejado.