Arquitetura Mobile

Para utilizar a versão atual do aplicativo é necessário que o CORS esteja corretamente configurado, conforme as documentações abaixo:

   - Configuração do CORS no JBOSS

   - Configuração do CORS no TOMCAT

A autenticação no DATASUL ocorre via cookie.

É necessário que o CORS esteja corretamente configurado e utiliza bearer token.

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, a autenticação por bearer token e a nova forma de comunicação entre o aplicativo e o servidor de aplicação.

Bearer token

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.

Como funciona a comunicação entre o IIS e o servidor de aplicação?

Na versão anterior do aplicativo, utilizavamos a camada de API's do FrameHTML para consumir os serviços necessários. Na nova versão, consumimos as API's que estão na camada do host para recuperar as informações necessárias. 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 gerar novamente 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.

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. Caso algum teste que seja executado pelo Postman falhe, significa que algum tipo de problema está impedindo o funcionamento correto do aplicativo. Por padrão, todas as API's (exceto a de healthcheck) não retornam informações detalhadas de erro por motivos de segurança. Caso seja necessário obter mais informações para algum tipo de erro nas API's em geral, basta adicionar a tag <add key="ShowCompleteLogErrorMyHr" value="true" /> dentro do Web.config na pasta FrameHTML:

Pelas especificações de infraestrutura dos clientes, já temos algumas ações mapeadas que podem resolver os problemas de configuração de ambiente. O primeiro passo é seguir os passos descritos no KCS https://centraldeatendimento.totvs.com/hc/pt-br/articles/360062680393-RH-RM-Meu-RH-Atualiza%C3%A7%C3%A3o-para-o-IONIC-5-0?source=search e realizar todas as configurações descritas. Dentre os casos mapeados, temos:

Portal e biblioteca instalados no mesmo servidor

Seguir apenas o KCS

Portal e biblioteca instalados em servidores distintos

A primeira verificação que deve ser feita é se o servidor de portal consegue "atingir" o servidor de aplicação e como ele faz isso (Através de IP, hostname, DNS, etc). Além disso, é necessário que a comunicação entre o servidor de portal e o de aplicação seja realizada através das portas API configuradas no serviços de host. Caso exista algum mecanismo de segurança entre a comunicação dos dois servidores (firewall, antivírus, proxy, etc) é necessário criar regras para liberar as portas API, caso contrário o aplicativo não irá funcionar. Por padrão o servidor de portal tentará se comunicar com o servidor de aplicação através do hostname. Se não for adequado para a configuração do cliente a utilização do hostname, será necessário adicionar a tag Host dentro dos arquivos RM.Host.Service.exe.config:

Outras configurações

Existem algumas configurações que podem ser utilizadas independente de como o cliente organizou sua infraestrutura. Abaixo listamos algumas das que já foram mapeadas.

        WebService - ServicesHostName

Em casos onde tenha WebService configurado através da tag ServicesHostName no RM.Host.Service.exe.config, a comunicação será feita através do endereço do WebService utilizando as portas de API configuradas no serviço de host.

        SubDomainMask ou múltiplas pastas FrameHTML

Existem casos onde o cliente utiliza apenas um servidor de aplicação que atende a diversos servidores de portal. Ele pode utilizar a configuração de Multi Tenancy(Configurando o RM Multi Tenancy (Multi Alias)) ou replicar diversas pastas FrameHTML apontando para o servidor de aplicação. Nesses casos não se pode utilizar a tag DefaultDB dentro dos serviços de host e sim a tag ServiceAlias dentro do arquivo Web.config na pasta FrameHTML. Além disso, é necessário adicionar a tag <add key="ConsiderServiceAliasMyHr" value="true" /> dentro do arquivo Web.config (Caso existam réplicas da pasta FrameHTML, copiar para todos).

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, etc) estejam barrando os headers. Além disso, caso o servidor web utilizado seja IIS, realizar a instalação do módulo adicional de CORS https://www.iis.net/downloads/microsoft/iis-cors-module. Um exemplo padrão de retorno dos cabeçalhos retornados abaixo:

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.

Certificado SSL é um certificado digital que autentica a identidade de um site e possibilita uma conexão criptografada. O termo "SSL" significa "Secure Sockets Layer" (camada de soquete seguro), um protocolo de segurança que cria um link criptografado entre um servidor Web e um navegador Web.

Empresas e organizações precisam adicionar certificados SSL aos seus sites para proteger as transações on-line e manter a privacidade e a segurança das informações dos clientes.

Verifique o seu certificado

No nosso aplicativo, em ambas plataformas (Android e iOS) utilizamos um browser para renderizar o nosso aplicativo. Isso implica na validação dos certificados assim como em qualquer site que você acessa normalmente por um browser comum. Para verificar se um determinado certificado é válido, recomendamos a validação através de portais como https://www.ssllabs.com/ssltest/ ou https://www.sslshopper.com/ssl-checker.html

Por exemplo, o SSLLabs realiza a geração de um grade/score baseado em uma série de critérios como por exemplo inspeção do certificado e protocolos de criptografia, nos casos abaixo o certificado gratuito ficou grade B, pois nível de criptografia suportado é inferior ao disponível no mercado, nesse link podem ser identificado metodologia de validação: https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

E se o meu certificado estiver inválido?

A tentativa de utilização de certificados inválidos geram erro no processo de handshake na validação das requisições e geração da chave de sessão entre o cliente requisitante e o servidor, consequentemente todas as suas informações não irão trafegar de modo seguro e criptografado pela rede. No exemplo da imagem abaixo, podemos observar que apesar de ser um certificado valido e configurado no server com sua chave privada, o mesmo não está autorizado a ser utilizado de acordo com o SAN, sendo rejeito pelo browsers no momento de negociação da chave de acesso para a sessão de comunicação. Ou seja, não podemos utilizar esse certificado para ser configurado em um IP externo ou mesmo em qualquer outro subdomínio, sendo assim realize essa verificação e validação para um correto funcionamento do ambiente seguro.

Certificados SSL Mobile

As plataformas de dispositivos móveis (IOS, Android) possuem limitações com relação aos certificados digitais. Por padrão, apenas os certificados homologados por elas são reconhecidos como confiáveis. Em geral, as maiores certificadoras são reconhecidas em ambos sistemas operacionais, porém  em caso de dúvidas, procure na sua unidade certificadora para assegurar que seu certificado é homologado para ambas plataformas. Para evitar a aquisição de certificados não homologados e outros problemas relacionados a segurança, é importante consultar a documentação técnica de cada plataforma sobre a lista de certificados reconhecidos como confiáveis: