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 Basic. Nas
variáveis ${email} e ${senha} devem ser passadas as informações do usuário para
acessar a API.
03 - Bearer Authentication no Robot
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:
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:
- Antonio Montanha
- Mayara Fernandes — Que sempre é um conteúdo
de referência no assunto Robot Framework
- QANinja
- https://www.brunobrito.net.br/jwt-cookies-oauth-bearer/
- (Parte 3) Segurança em APIs RESTful E aí vamos aprender mais sobre APIs Restful?thiagolima.blog.b
Show de bola, Vanessa!
ResponderExcluirAjudou muito!
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É necessário adicionar o argumento expected_status=any, assim ele não valida o status 2xx nas requisições
ExcluirOii 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.
ResponderExcluirEste comentário foi removido pelo autor.
ResponderExcluirNo '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?
ResponderExcluirSim, é 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