Season API Testing - Ep. 04: "401 unauthorized"  —  Agora é a hora de deixar o Robot entrar










Olááá Robotizadores, eu sou Vanessa Redes e estou invadindo esse blog (com autorização e devidamente autenticada 😁) para falar sobre como implementar requisições em APIs REST com autenticação e autorização pelo nosso Robot Framework!!! Então pega suas credenciais e vem comigo ...



  

01 - O que é Autorização e Autenticação em uma API REST?

Qualquer software hoje em dia precisa ter algum controle de segurança para os acessos, as APIs disponibilizam vários tipos de Autenticação, hoje vamos tratar de duas delas, a Básica e o Bearer com o seu JWT.


A primeira coisa que devemos esclarecer é o significado de Autorização e Autenticação, essa é fácil.
Autorização é o que você pode fazer, digamos que você tem acesso à Casa Branca mas não tem autorização para entrar no Salão Oval, ficou fácil?
E a Autenticação é quem você é, ou seja, é o guarda na entrada da Casa Branca verificando sua Identidade para ver se você é mesmo você.


O mais engraçado é que quando você acessa a sua API sem token, com token incorreto ou até mesmo com token que não tem autorização o erro que vai retornar é sempre o 401 unauthorized, de certa forma está errada, pois as vezes deveria ser “Not authenticated”, ou seja, eu nem sei quem você é.

02 - Basic Authentication no Robot

Falando nessas autorizações/autenticações existem vários tipos com protocolos e formas distintas. A mais simples de todas é a Basic Authentication, que é o básico “usuário” e “senha” enviados no header da API.

Vamos com um exemplo, para fazer essa autenticação do tipo básico devemos enviar as credenciais na hora de criar a sessão com a API, no campo “auth”, assim todas as rotas acessadas dessa API terão a “auth” já salva. O nosso Robot é super esperto e já entende que essa API requer uma autenticação do tipo BasicNas variáveis ${email} e ${senha} devem ser passadas as informações do usuário para acessar a API.

03 - Bearer Authentication no Robot




Bearer authentication (também conhecido como token authentication) é um Schema para autenticação HTTP (RC6750).

Authorization: Bearer <token>

"O Bearer identifica recursos protegidos por um OAuth2. O <token> deve ser um string. Ele representa uma autorização do server emitida para o client. Por sua vez, o client deve possuir mecanismos próprios para identificar e validar o Token.Referência: https://www.brunobrito.net.br/jwt-cookies-oauth-bearer/

Mas o que é esse “OAuth2”? O Thiago Lima descreveu de forma bem simples:

Não é apenas um método de autenticação, e sim um protocolo completo com diversas especificações de segurança. Ele é extremamente útil para o processo de autenticação e autorização e, por isso, atualmente é o método mais recomendado para o cenário de APIs.

Em curtas palavras para acessar uma API com esse tipo de autenticação você precisar logar primeiro, e depois que fizer o login com sucesso a API vai retornar um Token (que é aquela string criptografada). Esse Token vai ser solicitado em todas as requisições seguintes, então você deve enviar sempre no Headers da sua requisição seja ela um GET, POST, PUT, DELETE ou outra menos conhecida.

Algumas APIS têm algumas regras especificas com esse token, e já tive o prazer de trabalhar com três diferentes que me fizeram bater a cabeça um pouco e isso que eu venho trazer hoje.

Tem exemplo de API que você precisa só mandar o ${token} lá no header e fica tudo pronto, como fiz no post anterior com a API da Lojinha do Júlio de Lima.

No Post do Login da resposta pegamos o token e armazenamos em uma variável, depois setamos essa como uma variável de Suite para ser utilizada em todos os demais testes.


E nas demais requisições só precisamos passar no header no “campo” token a nossa variável. Impossível ser mais simples que isso, certo? Ah sim, o Basic é ainda mais fácil.

Passei pelas seguintes duas experiências que quero relatar aqui, algumas APIs você precisa passar além do Token mais alguma “coisinha”, os exemplos que tenho são JWT e o próprio Bearer

03.1 - Exemplo JWT

JWT é o próprio token de segurança (JWT = Json Web Token) e a API pode requisitar que você mande essa informação junto com o TOKEN, só devemos lembrar de adicionar isso antes da variável ${token}, a forma mais fácil é lá na hora de salvar essa variável já passar a palavra JWT assim nunca vai ser esquecido e aparecer um FAIL na sua tela.
t
E nas demais requisições é só mandar o ${token} normal como você pode ver ali no “Get Product”.

03.2 - Exemplo Bearer

E o último exemplo do dia é uma API que requisita enviar o Bearer junto do token, e a lógica é a mesma da JWT, tem que enviar a palavra antes do ${token}



Outro detalhe que quero mostrar é que usei duas formas diferentes de “capturar” o token das respostas, uma delas foi apenas passando o Set Suite Variable — ${token} — ${resp.json()[‘token’]}, simples assim pois o ${resp.json()[‘token’]} já é uma string então é só setar ela com escopo de suite e continuar usando sem medo.

E a outra foi através da keyword Get From Dictionary da Library Collections e nela você indica qual é o Dictionary no caso o JSON e indica qual o campo separado — token.

Para validar se o seu token está sendo capturado corretamente, lá no seu arquivo log.html você pode verificar ele sendo construído como segue abaixo:


Na keyword Set Suite Variable” você consegue validar se o token veio corretamente.

Outra dica de última hora e especialmente para a fase de aprendizado é usar a keyword que loga informações do teste:

Log To Console      Meu Token JWT é: ${token}

Assim nos Logs será possível validar se está capturando o token corretamente.



Espero que tenham gostado e aproveitado a leitura e o mais importante que as duvidas tenham sido sanadas e nunca mais você leia um “401 unauthorized

Aqui agradeço também ao Antonio Montanha que teve a paciência de me tirar algumas dúvidas teóricas enquanto eu tentava escrever esse post com essas experiências que me causaram algumas dores de cabeça. 



Referências:


Comentários

  1. Show de bola, Vanessa!
    Ajudou muito!

    ResponderExcluir
  2. Boa Tarde, queria saber como faço para validar um teste negativo, ou seja esperado um status code 400 ou 422, não consigo rodar o teste, pq o Robot interrompe com FAIL o teste, gostaria de um help.

    ResponderExcluir
    Respostas
    1. É necessário adicionar o argumento expected_status=any, assim ele não valida o status 2xx nas requisições

      Excluir
  3. Oii bom dia. Existe forma de pegar o time response de cada método da API sendo testado? Sem ser com o Get Current Date e subtraindo, pois acho que fica com bastante código repetido.

    ResponderExcluir
  4. Este comentário foi removido pelo autor.

    ResponderExcluir
  5. No 'Exemplo JWT' foi declarado valor pra variável ${token}? Em algum lugar é inserido o token ou o código vai buscar esse valor na API?

    ResponderExcluir
    Respostas
    1. Sim, é feita a requisição na linha 9 e na linha 11 está sendo declarada uma variável que obtém o token do json da resposta.

      Excluir

Postar um comentário

Postagens mais visitadas deste blog

[ATUALIZADO] Season Libraries - Ep. 01: Library Faker para informações aleatórias e fakes

Novo Curso: Robot Framework com Playwright e GitHub Actions

Season WEB Testing - Ep. 03: Open Browser - Chrome Options