NexTool Solutions

GLPI 11 ha i webhook nativi: a ogni ticket aperto, modificato o eliminato, avvisa un altro sistema via HTTP, con firma e nuovi tentativi. Li abbiamo testati sul nostro GLPI di supporto e la prima configurazione non ha consegnato nulla. Il motivo non compariva in nessuna schermata: GLPI rifiuta qualsiasi URL con una porta, come :8080 o la :5678 predefinita di n8n. Questa guida mostra come configurarli, cosa ha misurato il test e i tre dettagli che bloccano l'integrazione.

Serve andare oltre il webhook in uscita, con condizioni, più passaggi o ricezione di dati dall'esterno? Vedi Automazioni e webhook in GLPI con NexTool.

Cosa fa il webhook nativo (e cosa non fa)

Il webhook di GLPI 11 è in uscita: quando succede qualcosa su un elemento, GLPI compone un messaggio e lo invia a un URL. Serve per avvisare un ERP, aprire una card in Teams, alimentare una dashboard o avviare un flusso in n8n.

• Eventi: nuovo, aggiornamento ed eliminazione.
• Elementi: gli stessi della nuova API di GLPI 11, come ticket, problemi, cambiamenti, asset e utenti.
• Messaggio: per impostazione predefinita, l'elemento nel formato dell'API (stato, richiedente, team, entità, date), modificabile con variabili.

Non riceve nulla. Perché un altro sistema crei o modifichi ticket in GLPI, la strada è l'API.

Dove configurarlo

In Configurazione > Webhook > Aggiungi:

E nelle schede:

• Criteri: filtra quali elementi attivano l'invio, con gli stessi criteri della ricerca. Es.: solo i ticket della categoria "Acquisti".
• Editor del payload: sostituisce il messaggio predefinito con un tuo modello, con anteprima.
• Sicurezza: segreto della firma, sfida di validazione dell'URL e autenticazione OAuth.
• Intestazioni personalizzate: come Authorization o Content-Type.

Il test: cosa abbiamo misurato

Abbiamo creato due webhook nell'entità di test del nostro GLPI di supporto (azienda fittizia Acme) e aperto dei ticket. Uno puntava a una destinazione che risponde 200; l'altro, a una destinazione che risponde con errore 500.

I tre dettagli che bloccano l'integrazione

1. Gli URL con porta vengono rifiutati

GLPI 11 chiama solo gli URL che superano una lista di autorizzazione (protezione contro l'uso improprio del server). La regola predefinita accetta dominio, IP e percorso, ma non accetta la porta. L'errore non compare a schermo: resta nel webhook.log, come "Webhook target URL ... is unsafe".

Abbiamo testato la funzione di GLPI stesso:

Soluzione: pubblica la destinazione sulla porta predefinita (443 o 80), di solito dietro un reverse proxy. Questo risolve anche l'HTTPS. È possibile ampliare la lista con la costante GLPI_SERVERSIDE_URL_ALLOWLIST, ma vale per ogni accesso del server a URL esterni, quindi modificala con cautela.

2. Senza Content-Type, la destinazione potrebbe non capire il JSON

GLPI invia il corpo in JSON, ma senza l'intestazione Content-Type. Strumenti come n8n e molti framework leggono il corpo come JSON solo quando l'intestazione lo indica.

Soluzione: in Intestazioni personalizzate, aggiungi Content-Type: application/json.

3. Senza cron, non parte nulla

Il webhook non viene inviato subito: finisce in una coda, e l'azione automatica queuedwebhook invia ogni minuto, fino a 50 alla volta. Se il cron di GLPI non è in esecuzione, la coda continua solo a crescere.

Soluzione: cron da riga di comando ogni minuto (vedi il passo 6 di come installare GLPI 11) e, di tanto in tanto, un'occhiata a Configurazione > Webhook > Coda dei webhook.

Come validare la firma sulla destinazione

Ogni invio contiene due intestazioni: X-GLPI-timestamp (momento dell'evento) e X-GLPI-signature. La firma è l'HMAC-SHA256 del corpo seguito dal timestamp, con il segreto del webhook. In Python:

import hmac, hashlib

def assinatura_valida(corpo: bytes, timestamp: str, assinatura: str, segredo: str) -> bool:
    calc = hmac.new(segredo.encode(), corpo + timestamp.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(calc, assinatura)

Due accorgimenti: - Il timestamp è quello dell'evento, non dell'invio. Nei nuovi tentativi si ripete. Se rifiuti i messaggi "vecchi", lascia una finestra che copra i tentativi (qualche minuto). - Usa il corpo grezzo, così come è arrivato. Se il tuo codice decodifica e ricodifica il JSON, la firma non corrisponde.

Per chi ha bisogno di maggiori garanzie, la scheda Sicurezza offre la sfida di validazione: prima di inviare, GLPI chiama l'URL con un crc_token, e la destinazione deve rispondere con l'HMAC di quel token. C'è anche OAuth (client credentials): GLPI ottiene un token dal server di autorizzazione e lo invia come Bearer.

Quando il webhook nativo non basta

• Ricevere dati da un altro sistema: serve l'API.
• Logica con più condizioni e passaggi, come "se la categoria è X e il richiedente fa parte della direzione, avvisa un canale e apri un'attività": i Criteri filtrano, ma non concatenano azioni.
• Vedere in un'unica schermata cosa non è andato a buon fine e reinviare con un clic. La coda mostra lo stato, ma la diagnosi è nel webhook.log.

In questi casi entrano in gioco un orchestratore come n8n o il modulo Automazioni di NexTool.

Checklist prima di attivarlo in produzione

1. Destinazione in HTTPS, sulla porta predefinita, senza :porta nell'URL.
2. Intestazione Content-Type: application/json.
3. Firma validata sulla destinazione, con il corpo grezzo e una finestra temporale per i tentativi.
4. Criteri per non attivarlo su tutto.
5. "Numero di tentativi" in base all'importanza (3 è un buon inizio).
6. Cron di GLPI in esecuzione ogni minuto.
7. "Registra nella cronologia dell'elemento" attivo, perché il tecnico veda cosa è stato inviato.
8. Test con un ticket fittizio prima di aprire a tutti.

Test di NexTool del 3 ottobre 2026, sul GLPI 11.0.7 del nostro supporto, entità di test con dati fittizi. I webhook e i ticket di test sono stati eliminati in seguito. Comportamenti verificati anche nel codice sorgente di GLPI 11.