Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

  • Durante a configuração do dessa tag em seu 'appserver.ini' observe as validações do seu certificado e quais são os níveis de criptografia que permite a utilização.
  • Após estar tudo funcionando é indicado desabilitar o 'verbose' para evitar a atualização/gravação de mensagens informativas em seu 'console.log' o que pode afetar a performance do server.
  • Informe seu certificado e chave privada do seu certificado de acordo com as informações abaixo e também detalhadas no caso de uso do tópico anterior.
  • É importante habilitar também as palavras reservadas 'SSL' , pois sem estarem habilitadas as APIs REST não responderão, pois o O modelo de criptografia utilizada será automaticamente definida entre browsers e server baseado no certificado utilizado e nas versões de browsers do cliente, também para isso não podem existir gaps entre os modelos de criptografia, por exemplo, não é permitido pular o modelo, colocando SSL2=1 ; SSL3=0; TLS1_0=1.  
  • As tags corretas para declaração dos arquivos de certificados para essa chave são "CertificateCertificateServer" e "keyKeyServer". 
  • Não deixe de informar a 'PassPhrase', ou palavra/frase passe, pois ela é sua segurança para inibir acesso as informações de seu certificado utilizando função da Tech, como por exemplo a função PEMInfo() 

[SSLConfigure]
Enable=1
SSL2=1
SSL3=1
TLS1=1
TLS1_0=1
TLS1_1=1
TLS1_2=1
verboseVERBOSE=0
CertificateBUGS=1
STATE=1
CertificateServer=c:\totvs\certificate.crt
KeyKeyServer=c:\totvs\private.key
PassPhrase=meurhpwd

...

  • Inicialmente é importante ressaltar que problemas encontrados no certificado, como por exemplo, carregar em ambiente 'não seguro', poderá não funcionar o processo de login no aplicativo pelo celular, visto existem restrições de segurança de cada sistema operacional mobile, mesmo que o funcionamento ocorra normalmente pelo browser, onde nesse caso temos a possibilidade de permitir manualmente a habilitação do carregamento para URLs não seguras.

  • Provavelmente o seu serviço de APIs REST estará instalado em um servidor que responda a um IP Externo, consequentemente não faz sentido subir uma porta do REST que não possua o seu certificado SSL:
    • Caso deseje configurar uma API apenas com HTTP indicamos subir e utilizar um appserver apenas em um servidor físico em sua rede local.
    • Ao utilizar o SSL verifique as características do seu certificado baseado nas informações dos tópicos anteriores.
  • A palavra 'URL' dentro da tag [HTTPENV] deverá possuir inicialmente o conteúdo "/rest", pois é obrigatória para a utilização da arquitetura do App MeuRH, principalmente quando utilizada pelo celular:
    • Após a palavra "/rest" você poderá informar quaisquer nomes para compor a sua URL de APIs, em nosso caso de uso nossa URL ficaria por exemplo: https://104.210.222.191:8107/restT1
    • Entretanto, por nosso certificado criado não estar habilitado para esse IP público estaremos utilizando o serviço REST sem ssl para esse ambiente de teste, respondendo apenas em http://104.210.222.191:8107/rest
    • Sendo assim, apenas foi retirado as informações referente ao certificado da tag [HTTPREST].  
  • Referente a seção [RESTCONFIG], ela é criada exclusivamente para utilização da arquitetura do App MeuRH:
    • A palavra 'restPort'  é utilizada pelos serviços de backend por isso a obrigatoriedade do seu preenchimento, sendo assim, apesar do protheus em seu appserver permitir que se possa instanciar várias portas REST, em virtude da arquitetura do meurh esse contexto não é permitido.
    • Em relação a palavra reservada 'MeuRHLog' ela auxilia no processo de login e manutenção para identificar possíveis dificuldades no processo de configuração e divergências de login, posteriormente, também pode ser desligada utilizando o valor '0' para melhorar a performance de resposta do aplicativo.
  • Não deixe de confirmar se a porta do serviço REST utilizada está liberada em seu firewall para permitir receber as requisições.
  • As tags corretas para declaração dos arquivos de certificados dentro do serviço REST são "CertificateServerCertificate" e "keyServerKey".
  • Por questões de compatibilidade do protocolo de criptografia não deixe de informar essa tag "TLS1=3" no seu serviço REST.   
  • Não deixe também de habilitar o item 'SECURITY', pois ele é responsável em exigir as autenticações para a utilização das API´s, caso não estejam ligados o server responderá qualquer requisição recebida sem validação.

...

[HTTPREST]
Port=8107
SECURITY=1
URIs=HTTPENV
SSL2=1
SSL3=1
TLS1=3
TLS1_0=1
TLS1_1=1
TLS1_2=1
verbose=0
CertificateServerCertificate=c:\totvs\certificate.crt
KeyServerKey=c:\totvs\private.key
PassPhrase=meurhpwd

...

[HTTPS]
ENABLE=1
PATH=C:\Protheus_12127\Protheus_data\web
PORT=443
ENVIRONMENT=12.1.27
XFrameOptions = ALLOW-FROM http://meurh.world
Compression=1VERBOSE=1
SSL2=1
SSL3=1
TLS1=1
TLS1_0=1
TLS1_1=1
TLS1_2=1
CertificateServer=C:\Protheus_12127\bin\appserver\meurh_certificate.crt
KeyServer=C:\Protheus_12127\bin\appserver\meurh_private.key
PassPhrase=2020MeuRH#pwd


04. Sobre Configuração de Hosts/Seções HTTP

...

  • Quando estamos falando de multi-empresas ou grupo de empresas separadas falamos sobre dicionarios separados, por exemplo SX2T10 e SX2T20, para esses casos nossa indicação inicial é utilizar um appserver para cada empresa, podendo ser no mesmo servidor, isso facilita algum tipo de manutenção e controle se necessário.
    • Por exemplo, é possível configurar um appserver apenas com as seção do REST sem a seção HTTP que poderá estar localizado em outro appserver servindo as mesma porta. Enfim são muitas possibilidades de configuração, mas algumas podem sofrer restrições em virtude da arquitetura de conexão do aplicativo.
    • Modelos diferenciados de configuração necessitam uma revisão do arquivo 'properties.json' e da geração do QRCode para conexão.
  • Em relação ao serviço REST, em virtude da arquitetura do aplicativo, não poderemos utilizar a palavra reservada NÃO É POSSÍVEL UTILIZAR A CHAVE "prepareIn=ALL".
    • Apesar do serviço do Protheus ter a possibilidade de subir threads utilizando essa opção, o processo de autenticação do backend do Meu RH exige URLs Rest separadas, pois em alguns casos sua requisição pode cair no server . Pois caso contrário, a requisição poderá ser alocada no servidor em uma thread de outra empresa, pois no momento da requisição não existe a identificação do Tenent "TenantId "que se deseja acessar.

Todavia é possível configurar empresas simultaneamente no mesmo appserver, então abaixo indicaremos como é possível indicar essa informações:

  •  Inicialmente você deve configurar duas seções de environment (URIs) para as APIs Rest, uma para cada empresa, de acordo com o exemplo abaixo:
    • Pode-se utilizar a mesma porta REST para os dois ambientes, no caso port=8107.
    • Observe q temos as URLs  /restT1  &  /restT2, consequentemente serão responderão como  http://104.210.222.191:8107/restT1   &  http://104.210.222.191:8107/restT2

...

  • Para modelos de configuração sem utilização de SSL e sem complemento para o endereço do serviço rest ( URL=/rest  ), teremos as seguintes informações:
    •  "baseUrl": "http://104.210.222.191:8107/rest",
    • "rootContext": ""

  • Para modelos de configuração sem utilização de SSL e com complemento para o endereço do serviço rest ( URL=/rest T1 ), teremos as seguintes informações:
    •  "baseUrl": "http://104.210.222.191:8107/restT1",
    • "rootContext": "/T1/"

...