Introdução
Dando continuidade a série de artigos sobre ReactJS + Advpl, hoje irei apresentar a parte de segurança no REST do Protheus e como realizar o login no Protheus via REST. Caso você tenha interesse em ler os primeiros artigos dessa série, abaixo você tem uma lista contendo o título e o link de cada um deles.
Autenticação no REST
Vocês devem ter percebido que no teste realizado na parte 02 não foi necessário nenhum tipo de autenticação, essa tratativa não é legal quando falamos de ambiente de produção e principalmente de uma rotina que irá controlar permissões de acesso.
Vamos ativar então a segurança no REST alterando a tag “Security” na seção [HTTPREST] do appserver.ini, ficando assim:
[HTTPREST]
Port=9999
IPsBind=
URIs=HTTPURI
Security=1
Public=classe/path/get1,classe2/path/gety,classe3/path/post
Notenant=classe/path/get2,classe2/path/getv,classe3/path/post2
Se você tentar consumir a API do hello world agora vai obter o seguinte resultado:
Isso ai, não autorizado!
No Protheus existe nativo a API para autenticação, com isso não precisamos desenvolver todo processo de validar o usuário e gerar o token.
Essa API responde na rota: <server_rest_url>/api/oauth2/v1/token
Para consumir essa API iremos utilizar o métido POST e enviar algumas informações via “Query Params” , que a grosso modo são argumentos que são incluídos na URL e o endpoint de destino conhece e utiliza.
Query Params para autenticar e obter o token:
grant_type: password
username: admin
password: 1
Basicamente você deve informar o usuário e senha a ser autenticado no grant_type password.
Então no meu caso o request de login (session) no Insomnia ficará assim:
Enviando esse request, vamos obter a seguinte resposta caso as credenciais enviadas sejam válidas:
A API do Protheus retornou um objeto com algumas informações, vamos nas mais importantes:
"access_token": Token autorizado a consumir os endpoints no REST
"refresh_token": Caso o access_token tenha expirado, podemos utilizar esse token para solicitar a atualização do prazo de validade do token.
"token_type": Informa que o token é do tipo Bearer
"expires_in": informa o tempo de validade do token em segundos
De posse do access_token podemos agora testar novamente o consumo da nossa API de hello world que parou de funcionar, para isso precisamos enviar o token no Header da requisição conforme abaixo:
Na aba “Header” informe a propriedade “Authorization” com o token. É necessário ter atenção nesse momento, pois o access_token deve ser enviado no seguinte formato: Bearer <Token>
Exatamente assim, a string Bearer + espaço + access_token recebido no login.
exemplo:
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJUT...
Resultado do consumo enviando o token:
Vamos revisar o quanto nosso projeto já evoluiu:
- Criamos a tabela Z20 responsável por registrar as permissões
- Configuramos o Protheus para trabalhar como servidor REST
- Criamos uma API em ADVPL de Hello World para testar
- Ativamos a autenticação no Rest Protheus e conseguimos recuperar o token
Bônus
Não faz parte do escopo do nosso projeto a inclusão de usuários no Protheus via API REST, mas como está tendo bastante procura sobre o uso de REST no Protheus vou deixar um bônus explicando como criar usuários no Protheus através da API REST.
Imagine na implantação do ERP Protheus ser possível cadastrar os usuários de forma automatizada? Pois é, isso é possível e vamos ver como logo abaixo:
Criar usuário via REST
O endpoint responsável pela criação de usuários no Protheus responde o método POST na rota: <server_rest_url>/api/framework/v1/users
Para que seja possível incluir um usuário no Protheus será necessário estar autenticado, esse processo foi explicado logo acima nesse mesmo artigo.
Vamos mandar no Header da requisição o nosso token conforme exemplo abaixo:
Agora o BODY da requisição em JSON ficará assim:
Vamos aos detalhes de cada parâmetro enviado:
userName //Login do usuário (string)
displayName //Nome completo (string)
title //Cargo (string)
emails //Array de e-mails (array)
value //Cada e-mail deve ir em um value (string)
primary //Informa se é o e-mail principal (boolean)
active //Usuário está ativo (boolean)
password //Senha inicial desse usuário ((string)
groups //Array de grupos que esse usuário pertence (array)
value //Cada código de grupo deve ir em um value (string)
urn:scim:schemas:extension:totvs:2.0:User/forceChangePassword //Indica se deve trocar a senha no próximo login (boolean)
urn:scim:schemas:extension:enterprise:2.0:User/employeeNumber //Empresa e filial que usuário pode acessar (string separado por | )
urn:scim:schemas:extension:enterprise:2.0:User/department //Departamento do usuário
urn:scim:schemas:extension:totvs:2.0:User/groupRule //Define a regra de priorização por grupo: 1 priorizar, 2 desconsiderar e 3 somar (integer)
Estando todos os parâmetros corretos, teremos o seguinte retorno:
Usuário criado com sucesso !!
Listar usuários via REST
Vamos listar todos os usuários que estão cadastrados?
Basta fazer uma requisição no método GET via rota: <server_rest_url>/api/framework/v1/users
Nessa rota também precisamos enviar o token no Header igual para criar o usuário. Além do token no Header, podemos enviar também um “Query Params” chamado “showAdmin” informando que queremos listar também o usuário administrador:
Enviando a requisição, temos como resultado todos os usuários cadastrados no ERP.
Existem também os métodos de atualização e exclusão dos usuários, caso queiram que eu fale sobre eles me avisem!
É isso aí, no próximo artigo vamos começar a construir nossa API de CRUD para a tabela Z20, não percam!
1 Comment