OnAllow

Atenção!

Recurso disponível somente em: APPSERVER 24.3.0.5 + TLPPCORE 01.05.03

O onAllow é o inverso de onBlock, ou seja, através da função de callback onAllow, o usuário/desenvolvedor pode definir quais serviços REST ( Endpoints + método ) serão permitidos para uso ou somente ocultados na listagem de serviços disponíveis.

Esse recurso é útil quando queremos manter disponíveis somente alguns serviços REST para determinado ambiente.

Informações Importantes

Os endpoints + métodos que não forem informados em OnAllow serão automaticamente bloqueados.
A função informada em onAllow será executada somente na subida do REST, antes da criação do mapa de serviços que serão disponibilizados no serviço REST.
A chave OnAllow só será lida quando informada na Thread Pool, pois ela está diretamente relacionada ao servidor REST. Portanto, caso seja configurado OnAllow nas sessões destinadas aos Slaves, estas serão ignoradas e não terão uso algum para o ambiente REST.
OnAllow tem prioridade de funcionamento sobre OnBlock, ou seja, caso ambos sejam configurados no mesmo ambiente, somente OnAllow será ativado e OnBlock será ignorado.

Parâmetro Recebido

A função customizada recebe somente 1 (um) parâmetro, sendo:

1 - oList

Classe contendo valores da execução e métodos para informar que determinado Endpoint + Método deve ser permitido ou oculto.

Métodos Sets

oList:allow()

oList:allow( cEndpoint as character, cMethod as character )

Responsável por adicionar um Endpoint e Método que será permitido no ambiente REST, inclusive visível em todas as listagens.

Ex:

Sintaxe

oList:allow( cEndpoint, cMethod )

oList:hide()

oList:hide( cEndpoint as character, cMethod as character )

Responsável por adicionar um Endpoint e Método que será somente ocultado no ambiente REST, ou seja, ele não aparece em nenhuma listagem de serviços disponíveis, porém, quem conhecer a sua assinatura poderá acessá-lo.

Ex:

Sintaxe

oList:hide( cEndpoint, cMethod )

Métodos Gets

oList:getServiceName()

oList:getServiceName()

Retorna o nome do serviço REST o qual foi configurado o onAllow.

[HTTPSERVER]
Servers=SERVIDOR_REST_01

oList:getServicePort()

oList:getServicePort()

Retorna a porta do serviço REST o qual foi configurado o onAllow.

[HTTPSERVER]
Servers=SERVIDOR_REST_01
 
[HTTP_DBMONITOR]
port=8080

oList:getThreadPoolName()

oList:getThreadPoolName()

Retorna o nome do Thread Pool do serviço REST o qual foi configurado o onAllow.

[HTTPSERVER]
Servers=SERVIDOR_REST_01
 
[SERVIDOR_REST_01]
port=8080
locations=LOC_SRV_01

[LOC_SRV_01]
ThreadPool=THREAD_POOL_SRV_01

oList:getUserData()

oList:getUserData()

Retorna o JSON informado em UserData do serviço REST o qual foi configurado o onAllow.

[HTTPSERVER]
Servers=SERVIDOR_REST_01
 
[HTTP_DBMONITOR]
userData={"sua_chave":"seu_valor"}

oList:getApiList()

Retorna um Json contendo os endpoints que foram encontrados para serem disponibilizados neste ambiente. A lista contém endpoints criados via annotation e via inicialização dinâmica do server através de LoadURNs.

O recebimento dessa lista é opcional pois pode degradar a performance da subida da aplicação (AppServer), portanto o comportamento padrão é o não recebimento da lista de APIs.

Para ativar o recebimento, informe através da configuração do REST na chave TlppData, conforme abaixo:

INI

TlppData={"OnAllowGetApiList":true}

Inicialização Dinâmica

jTP_TlppData := {"OnAllowGetApiList":true}
jREST['ThreadPool']['TlppData'] := jTP_TlppData

JSON enviado ao callback

JSON retornado quando não requisitada a lista

{
    "required": false,
    "success": false,
    "annotation": [],
    "json": []
}

JSON contando APIs

{
    "required": true,
    "success": true,
    "annotation": [
        { "/exemplo1/annotation": ["GET","POST","PUT"] },
        { "/exemplo2/annotation": ["GET"] }
    ],
    "json": [
        { "/exemplo1/loadurn": ["GET"] }
    ]
}

Retorno

Sugerimos que o retorno seja NULL pois todo e qualquer retorno será ignorado.

Exemplo

function U_onAllow( oList )

  local cEndpoint as character
  local cServiceName as character
  local nServicePort as numeric
  local cThreadPoolName as character
  local cUserData as character
  local jApis as json

  // Use os valores abaixo conforme sua necessidade de implementação
  // Embora você sempre receberá tais valores, seu uso é opcional.
  
  cServiceName    := oList:getServiceName()
  nServicePort    := oList:getServicePort()
  cThreadPoolName := oList:getThreadPoolName()
  cUserData       := oList:getUserData()
  jApis           := oList:getApiList()

  // Para permitir ou ocultar algum serviço, utilize os métodos Sets

  cEndpoint := '/exemplo1/urn'
    oList:allow( cEndpoint, 'get'  )
    oList:allow( cEndpoint, 'post' )
    oList:hide(  cEndpoint, 'put'  )

  cEndpoint := '/exemplo2/urn'
    oList:allow( cEndpoint, 'get' )

return

ConclusãoÉ muito simples permitir/ocultar um serviço REST, basta utilizar um dos métodos mencionados acima indicando a ação (allow | hide) e o Endpoint e seu método.
Note que sempre é preciso informar o Endpoint e Método para cada ação, sendo assim, poderemos permitir todos os métodos de um mesmo Endpoint, ou permitir uns e outros não, conforme necessidade.

Importante!

Devido à criticidade de disponibilizar dados indesejados, caso ocorra alguma "exception" na criação da lista o AppServer não será reiniciado.

Porém, se essa criticidade não for a sua realidade e ainda assim queira que o AppServer seja iniciado, mesmo que disponibilizando todos os serviços REST, é possível configurar o REST indicando que o OnAllow seja executado em modo "Soft", conforme abaixo:

[HTTPSERVER]
Servers=SERVIDOR_REST_01
 
[SERVIDOR_REST_01]
port=8080
locations=LOC_SRV_01

[LOC_SRV_01]
ThreadPool=THREAD_POOL_SRV_01

[THREAD_POOL_SRV_01]
TlppData={"OnAllowSoft":false}

Árvore de páginas