Arquitetura do funcionamento atual do mobile

01. OBJETIVO

Falar sobre a arquitetura do Meu RH no mobile a partir da versão 2.0.0.

02. O QUE USAMOS DO APARELHO?

a) GPS (opcional)

 - Utilizado para obter a localização do usuário quando ele bate o ponto.

b) Câmera (opcional)

          - Utilizado para ler QR Code e tirar foto do atestado/abono.

c) Biometria (opcional)

- Utilizado na autenticação.

03. DATASUL

É necessário que o CORS esteja corretamente configurado.

   - Configuração do CORS no JBOSS

   - Configuração do CORS no TOMCAT

A autenticação no DATASUL ocorre via cookie.

a) JBOSS

É realizado uma requisição POST em /dts/portal-hcm/rest/auth/login. É enviado os dados do usuário via request payload:

A resposta deverá possuir http status 200 e o seguinte corpo:

Caso as credenciais estejam incorretas será retornado http status 500 com o seguinte corpo:

Esquema novo de login (a partir da 2.3.0):

2. Caso o login tenha acontecido com sucesso é transmitido as credenciais do usuário via mensagem entre a webview do mobile e webview do portal.

Esquema antigo de login (anterior a 2.3.0):

2. Caso o login tenha acontecido com sucesso é transmitido as credencias do usuário para o portal via localstorage e depois o item é deletado do localstorage

b) TOMCAT 

É realizado uma requisição GET em /api/rh/v1/login/auth/aniassana. A autenticação ocorre via basic auth definido pelo frame.

       A resposta deverá possuir http status 200 e o seguinte corpo:

       Caso as credenciais estejam incorretas será retornado http status 401 com o corpo vazio.

Login com SSO-FILTER ativo (passando pela página de login do frame):

2. É preenchido automaticamente as credenciais do usuário na página de login do frame. Caso aconteça algum erro de autenticação nessa página a página será exibida para o usuário (ocasionando o que os usuários acreditam ser o bug de login em 2 telas).

Login com SSO-FILTER desativado:

Esquema novo de login (a partir da 2.3.0):

2. Caso o login tenha acontecido com sucesso é transmitido as credenciais do usuário via mensagem entre a webview do mobile e webview do portal.

Esquema antigo de login (anterior a 2.3.0):

2. Caso o login tenha acontecido com sucesso é transmitido as credencias do usuário para o portal via localstorage e depois o item é deletado do localstorage

04. PROTHEUS

É necessário que o CORS esteja corretamente configurado.

Utiliza bearer token

05. RM

Desde 09/2021 estamos utilizando nosso aplicativo com o framework Ionic na versão 5. Em relação a versão anterior, tivemos algumas mudanças e as principais delas foram a utilização do mecanismo de CORS e a autenticação por bearer token.

O CORS (Cross-origin Resource Sharing) é um mecanismo utilizado pelos navegadores para compartilhar recursos entre diferentes origens. O CORS é uma especificação do W3C e faz uso de headers do HTTP para informar aos navegadores se determinado recurso pode ser ou não acessado. Para atender o correto funcionamento do mecanismo de CORS e mantendo a infraestrutura que os clientes já possuíam, estamos utilizando agora o modelo de API's do host disponibilizadas pelo nosso time de framework. É necessário sempre verificar se as requisições do tipo OPTIONS estão sendo feitas e o retorno deve conter os cabeçalhos necessários de CORS. Por isso, é importante verificar que eles estão sendo retornados de maneira correta e que nenhum tipo de mecanismo de segurança (firewall, antivírus, proxy) estejam barrando os headers. Um exemplo padrão de retorno dos cabeçalhos retornados abaixo:

O endereço de acesso as API's do host é diferente da camada de API's do FrameHTML e não poderíamos realizar alterações de infraestrutura nesse aspecto, pois obrigaria o cliente a regerar o QR Code de ambiente. Dessa forma, estamos utilizando a camada de FrameHTML como uma espécie de client para o host, sendo que todas as requisições ainda são encaminhadas para a camada de FrameHTML e de lá são redirecionadas para o host. Para realizar a comunicação entre a camada FrameHTML e a camada do host são utilizadas as portas de API configuradas dentro dos serviços de host. Para isso, é importante se atentar que caso os servidores de aplicação e de portal sejam separados, não pode haver qualquer tipo de bloqueio sobre as portas de API do host e o servidor de portal deve ser capaz de se comunicar através delas.

Outra novidade na versão do Ionic 5 é a utilização do bearer token para autenticação do usuário ao invés do processo de basic authentication. A bearer authentication (também chamada de autenticação por token) é um esquema de autenticação HTTP que envolve tokens de segurança chamados bearer tokens. O nome "Bearer token" pode ser entendido como "dar acesso ao portador deste token". O bearer token é uma string criptografada, gerada pelo servidor em resposta a uma solicitação de login. O client deve enviar este token no cabeçalho de autorização ao fazer solicitações para recursos protegidos. Utilizamos a API Autorização / Autenticação Basic e Bearer Token que retorna um token contendo as informações do usuário e outras claims que são relevantes para ele.

Para validar o funcionamento do aplicativo na nova versão, foram desenvolvidos dois scripts dentro da ferramenta Postman, que tem como objetivo simular as principais requisições realizadas pelo aplicativo. Um desses scripts simula de fato o comportamento do app, validando o login, CORS e o consumo de serviços em geral (Pode ser executado de qualquer máquina). Já o outro script tem como objetivo consumir algumas das api's que estão dentro do host (Precisa ser executado de dentro da máquina onde exista o serviço de host). O passo-a-passo para executar os scripts estão no documento https://docs.google.com/document/d/1Jr7It3jhl2aUJBpy9T4c7QtxTU51J9SlGLy8JDsQ8PA/edit?usp=sharing

06. OBSERVAÇÕES GERAIS

        Para testar se o servidor está com CORS configurado corretamente basta fazer uma requisição POST/PUT/DELETE (não pode GET) em alguma URL da API colocando o Header "Origin" com valor "http://localhost", como por exemplo:

A resposta do servidor deverá possuir em seu header "Access-Control-Allow-Origin" com "http://localhost".

Caso o servidor não responda isso o CORS não está configurado corretamente e ocorrerá erros no login do mobile.