Personalizzazione richiesta http di negoziazione

La modalità di negoziazione con tipo “Personalizzato” consente di definire la richiesta http inoltrata all’endpoint di negoziazione token e il parsing della risposta ottenuta.

Nella sezione “Dati Richiesta” vengono definiti i parametri della richiesta HTTP. I dati presenti possono essere definiti tramite costanti o possono contenere parti dinamiche risolte a runtime dal Gateway (per maggiori dettagli Valori dinamici).

• Metodo HTTP: tipo di richiesta (es. GET, POST, …);

• Content-Type: presente solamente per tipi di richieste che prevedono l’invio di un payload, ne definisce il tipo di messaggio inviato;

• Header HTTP: consente di indicare per riga eventuali header HTTP (nome=valore) da inserire nella richiesta;

• Tipo Template Payload: definisce la modalità con la quale viene successivamente fornito il payload http:

  • Template: il payload viene definito tramite un template che può contenere parti dinamiche risolte a runtime definite tramite una sintassi proprietaria di GovWay (per maggiori dettagli Valori dinamici);

  • Freemarker Template: il payload viene definito utilizzando il template «Freemarker» (https://freemarker.apache.org/);

  • Velocity Template: il payload viene definito utilizzando il template «Velocity» (http://velocity.apache.org/);

• Payload HTTP: payload http inviato nella richiesta.

Nelle figure Fig. 391 e Fig. 392 vengono rispettivamente mostrati un esempio di configurazione di una richiesta http definita tramite un metodo che non prevede l’invio di un payload e un altro esempio che lo prevede.

Dal token endpoint si attende un formato della risposta che sia conforme al json definito nello standard RFC 6749. Il parser utilizzato per default dalla configurazione, mostrato nella figura Fig. 393, è quello che consente di processare i claims definiti nel RFC e riportati nella tabella seguente.

È possibile in alternativa definire un mapping puntuale tra il nome di un claim e l’informazione che GovWay cerca di estrarre dal token. Come mostrato nella figura Fig. 394 il mapping viene richiesto per ogni claim definito nella tabella descritta precedentemente.

In alternativa è possibile indicare di utilizzare direttamente il payload di risposta HTTP come access token. In questo scenario, mostrato nella figura Fig. 395, dovrà essere definito l’intervallo temporale di validità del token acquisito.

Infine è possibile indicare il nome di una classe che implementa una logica di parsing personalizzata. La classe deve implementare l’interfaccia «org.openspcoop2.pdd.core.token.parser.INegoziazioneTokenParser» (Fig. 396).