Considerazioni sull'integrazione

Questa guida passo passo ti aiuta a prendere decisioni su tutti i principali problemi di integrazione.

Accedi con Google in astratto

Di seguito sono riportati i passaggi generali che gli utenti possono utilizzare per accedere / registrarsi al tuo sito web.

  1. Gli utenti accedono a un sito web Google.

    Affinché Accedi con Google funzioni, deve essere presente una sessione Google attiva nel browser. One Tap e Accesso automatico vengono attivati solo quando gli utenti hanno eseguito l'accesso a Google prima di caricare le tue pagine web. Questo passaggio è facoltativo per il flusso del pulsante Accedi con Google, poiché agli utenti viene chiesto di accedere a Google quando il pulsante viene premuto.

  2. Gli utenti sfogliano le tue pagine web dove sono incorporati i pulsanti One Tap, Accesso automatico o Accedi con Google.

  3. Gli utenti interagiscono con One Tap, il pulsante Accedi con Google e i successivi flussi UX in modo da:

    • Seleziona una sessione Google attiva per continuare.
    • Ottieni il consenso degli utenti finali per la condivisione delle informazioni del profilo con il tuo sito web, se non hanno ancora acconsentito.

    Quando nel browser è attiva una sola sessione Google,

    • Con un semplice tocco viene selezionata automaticamente l'unica sessione e quindi viene saltata la pagina del selettore account.
    • Il pulsante Accedi con Google rimane nella pagina del selettore account, che consente agli utenti di aggiungere una nuova sessione Google quando necessario.

    Se l'Account Google selezionato non è stato utilizzato in precedenza con il tuo sito web o se l'autorizzazione è stata revocata, viene visualizzata una pagina per il consenso.

    Consenso per il pulsante Accedi con Google

    Una volta approvata, Google registrerà la decisione, così da saltare la pagina del consenso per la prossima volta.

  4. Una credenziale di token web JSON (o token ID) contenente il nome, l'email e l'immagine del profilo dell'utente viene condivisa utilizzando un gestore di callback JavaScript o l'invio di un post al tuo servizio di backend.

    Lo scopo della restituzione dei token ID al gestore di callback JavaScript sul lato client non è la decodifica nel codice JavaScript, ma l'invio al server a tuo piacimento. Un buon esempio è utilizzare un oggetto XmlHttpRequest per evitare il ricaricamento della pagina causato dall'invio del post.

  5. Sul lato server, la credenziale JWT rilasciata da Google viene convalidata e utilizzata per creare un nuovo account o stabilire una sessione autenticata sul tuo sito web.

    Potrai gestire lo stato di accesso degli utenti sul tuo sito web.

    Lo stato di accesso all'Account Google dell'utente e la tua app sono indipendenti l'uno dall'altro, tranne che al momento dell'accesso, quando sai che l'utente ha eseguito l'autenticazione e ha eseguito l'accesso al proprio Account Google. Gli utenti possono rimanere collegati all'account, uscire o passare a un altro Account Google mantenendo una sessione attiva sul tuo sito web con accesso eseguito.

Riassumendo, come per l'accesso basato su password, Accedi con Google offre un altro modo per autenticare gli utenti sul Web. Accedi con Google non fornisce funzionalità per la gestione delle sessioni sul tuo sito web dopo l'autenticazione.

Accedi alle API e ai servizi di Google

Dopo aver integrato l'API di autenticazione, come descritto sopra, potresti dover integrare l'API di autorizzazione, se il tuo sito deve accedere alle API e ai servizi Google per conto di utenti autenticati. Sebbene l'autenticazione fornisca al tuo sito token ID per autenticare gli utenti, l'autorizzazione fornisce al sito token di accesso (separati) e autorizzazioni per utilizzare le API e i servizi di Google. Per ulteriori informazioni, consulta la sezione Autorizzazione per il Web.

Separazione dell'UX per l'autenticazione e l'autorizzazione

Se il tuo sito web deve chiamare entrambe le API di autenticazione e autorizzazione, devi chiamarle separatamente in momenti diversi. Consulta la sezione Separare i momenti di autenticazione e autorizzazione.

Se in passato il tuo sito web ha richiesto token di autenticazione e di autorizzazione contemporaneamente, quando utilizzi la libreria JavaScript dei Servizi di identità Google, devi modificare l'esperienza utente in modo da separare il momento dell'autenticazione da quello dell'autorizzazione.

  • Al momento dell'autenticazione, il tuo sito web può integrarsi con il pulsante One Tap, Accesso automatico o Accedi con Google per consentire agli utenti di accedere o registrarsi al tuo sito web.
  • Al momento dell'autorizzazione, il tuo sito web può richiamare l'API di autorizzazione per ottenere le autorizzazioni e i token per accedere alle API o ai servizi di Google.

Per una transizione UX fluida e una riduzione della complessità, una pratica comune consiste nel suddividere il processo in due passaggi separati.

  1. Esegui il refactoring dell'UX per separare i momenti di autenticazione e autorizzazione.

  2. Esegui la migrazione alla libreria JavaScript dei Servizi di identità Google.

Confronto tra API HTML e API JavaScript

Puoi utilizzare l'API HTML o l'API JavaScript per integrare One Tap, Accesso automatico o Pulsante Accedi con Google nelle tue pagine web.

Con l'API HTML, hai a disposizione più funzionalità integrate. Ad esempio,

  • Eseguire il rendering del pulsante One Tap o Accedi con Google al caricamento della pagina.
  • Invia la credenziale restituita all'endpoint lato server specificato dall'attributo data-login_uri dopo il completamento dell'esperienza utente con One Tap, Accesso automatico o popup/reindirizzamento dei pulsanti.
  • Impedisci gli attacchi CSRF Double-submit-cookie.
  • Utilizza il generatore di codice per generare il codice HTML, quindi copialo semplicemente nelle pagine HTML.

Con l'API HTML, puoi anche scrivere codice JavaScript per personalizzare il comportamento.

  • Puoi scrivere il tuo gestore di callback, quindi impostare il nome della funzione sull'attributo data-callback. Un buon esempio è utilizzare un metodo XmlHttpRequest per inviare la credenziale restituita al server, per evitare il ricaricamento della pagina causato dall'invio post predefinito.

Con l'API JavaScript hai una maggiore flessibilità in alcuni scenari, come descritto di seguito.

  • Esegui il rendering del pulsante One Tap e del pulsante Accedi con Google in un secondo momento. Ad esempio, dopo che gli utenti avranno selezionato Accedi dal menu.
  • Chiamare l'API più volte. Ad esempio, il pulsante Accedi con Google deve essere visualizzato ogni volta che viene visualizzata la finestra di dialogo di accesso.
  • Generando le pagine HTML in modo dinamico, rendendo difficile l'incorporamento del codice di chiamata API al loro interno.
  • Carica la libreria JavaScript dei Servizi di identità Google in un secondo momento.

Il codice API HTML può essere richiamato solo una volta nell'evento onload della pagina o nell'evento onload della libreria JavaScript dei Servizi di identità Google, a seconda dell'evento che si verifica dopo. Devi utilizzare l'API JavaScript se il comportamento dell'API HTML non soddisfa le tue aspettative.

Non utilizzare l'API HTML con l'API JavaScript nella stessa pagina web per l'inizializzazione della pagina o per il rendering di One Tap e pulsanti. Controlla il tuo codice, sia HTML che JavaScript, per verificare la presenza di punti in cui possono sovrapporsi. Tieni presente quanto segue:

  • Stai utilizzando l'API HTML se nel codice HTML sono presenti uno o più elementi in <div id='g_id_onload' ... ><id> o <div class='g_id_signin' ...></div>.
  • Utilizzi l'API JavaScript se uno o più metodi in initialize(), prompt() o render() vengono richiamati nel codice JavaScript, indipendentemente dal fatto che siano incorporati o caricati da un file JavaScript separato.

Le seguenti API JavaScript possono essere utilizzate indipendentemente dall'inizializzazione o dal rendering di One Tap e pulsanti; non dispongono di API HTML corrispondenti:

Considerazioni sul pulsante Accedi con Google

Popup / reindirizzamento

La specifica OAuth 2.0 considera il reindirizzamento HTTP, ma non dispone di indicazioni sul rendering delle finestre di dialogo popup. L'esperienza utente popup, soprattutto sul Web desktop, può fornire una UX migliore per gli utenti finali. Questo perché gli utenti non vengono reindirizzati dalle pagine di terze parti e una finestra popup simile a una finestra di dialogo fornisce un'esperienza contestualizzata per la concessione delle autorizzazioni.

Con l'esperienza utente popup, il provider di identità deve basarsi su canali di comunicazione multiorigine lato client per passare le risposte OAuth dalla finestra popup, in cui è visualizzata la pagina di consenso del provider di identità, alla finestra principale, dove è visualizzata la pagina di terze parti. Di solito, i codici JavaScript sono necessari su entrambi i lati per inviare e ricevere la risposta OAuth in più finestre.

Sia l'esperienza utente popup sia quella di reindirizzamento sono supportate dal pulsante Accedi con Google. Per impostazione predefinita, viene utilizzata l'UX popup. Puoi modificare l'esperienza utente impostando l'attributo data-ux_mode.

Esistono alcune differenze tra il flusso di reindirizzamento dei pulsanti Accedi con Google e il flusso di reindirizzamento OAuth.

  • Il flusso di reindirizzamento dei pulsanti Accedi con Google utilizza sempre il metodo POST per inviare la credenziale al server web, mentre il reindirizzamento OAuth di solito utilizza il metodo GET.
  • I parametri inviati dal flusso di reindirizzamento del pulsante Accedi con Google sono diversi da quelli del flusso di reindirizzamento OAuth.

Per gli sviluppatori che utilizzano l'API HTML, indipendentemente dall'esperienza utente utilizzata, le credenziali vengono sempre inviate a data-login_uri con il metodo POST e gli stessi parametri. In questo modo puoi cambiare la modalità UX senza altre modifiche al codice. Per l'esperienza utente di reindirizzamento, è necessario aggiungere data-login_uri agli URI di reindirizzamento autorizzati per il client nella console API di Google.

Personalizzazione dei pulsanti

L'uso del tuo pulsante non è supportato. Non esiste un'API per avviare in modo programmatico il flusso di un pulsante.

Per attivare il flusso dei pulsanti Accedi con Google, devi soltanto eseguire il rendering di uno o più pulsanti Accedi con Google nelle tue pagine web. Il flusso dei pulsanti viene avviato e gestito in modo trasparente quando gli utenti fanno clic su questi pulsanti.

L'API Button Rendering ti consente di personalizzare l'aspetto del pulsante Accedi con Google. Ti consigliamo di utilizzare il generatore di codice per progettare in modo interattivo i pulsanti. Anche se utilizzi l'API JavaScript, puoi generare prima il codice HTML, quindi copiarlo nei campi corrispondenti dell'API JavaScript.

Non esiste un'API per consentire ai siti web di controllare se le informazioni personalizzate devono essere utilizzate per visualizzare i pulsanti. I pulsanti personalizzati vengono visualizzati se tutte le condizioni sono soddisfatte. Ulteriori dettagli sono disponibili nella pagina Informazioni sul pulsante Personalizzato.

Puoi inserire più pulsanti nella stessa pagina web. Il generatore di codice può creare un solo pulsante alla volta. Puoi eseguirlo più volte e copiare il codice <div class='g_id_signin' ...></div> generato nella pagina web.

Best practice per il rendering dei pulsanti

Per motivi di privacy, il pulsante personalizzato viene mostrato in un iframe dal dominioaccounts.google.com. Il caricamento di un iframe può richiedere molto tempo in una rete lenta. Per mitigare questo problema di latenza, il rendering dei pulsanti viene eseguito in due passaggi, come segue:

  1. La versione di un pulsante incorporato viene visualizzata nell'albero DOM del tuo sito web. È solo un pulsante di testo e non è possibile usare informazioni personalizzate. Lo scopo è consentire agli utenti di visualizzare il pulsante il prima possibile.
  2. Viene inviata una richiesta iframe a Google per caricare l'iframe del pulsante, che potrebbe contenere informazioni personalizzate. Una volta caricato l'iframe del pulsante, il pulsante della versione incorporata viene rimosso.

Di seguito sono elencate alcune best practice per ridurre al minimo la latenza di visualizzazione del pulsante di flusso del pulsante Accedi con Google.

  • Carica la libreria JavaScript dei Servizi di identità Google il prima possibile. Potresti caricare la libreria JavaScript prima di altre librerie di grandi dimensioni, soprattutto sul Web mobile.

  • Se il pulsante Accedi con Google viene visualizzato solo dopo che l'utente ha selezionato Accedi dal menu. Puoi visualizzare il pulsante Accedi con Google prima in un elemento nascosto, quindi renderlo visibile dopo che l'utente seleziona Accedi dal menu.

Considerazioni relative a One Tap

Accesso automatico

L'accesso automatico annullabile offre i seguenti vantaggi.

  • Potrebbe migliorare la percentuale di accesso salvando un'azione dell'utente.
  • A differenza dell'accesso silenzioso fornito dalla libreria JavaScript Accedi con Google deprecata in precedenza, gli utenti vedono sempre un'interfaccia utente quando si verifica l'accesso automatico, il che fornisce loro il contesto del motivo e della modalità di accesso al tuo sito web. Gli utenti hanno anche la possibilità di annullare se lo desiderano.
  • Seleziona automaticamente l'account utilizzato dall'utente in precedenza, impedendo all'utente di creare account duplicati sul tuo sito web.

L'attivazione o meno dell'accesso automatico è una decisione che devi prendere in base ai requisiti aziendali e all'esperienza utente del tuo sito web. In particolare se la maggior parte delle disconnessioni dal tuo sito web è causata dal timeout della sessione anziché da scelte esplicite dell'utente, l'accesso automatico può essere un buon modo per i tuoi utenti di recuperare lo stato della sessione.

Quando visualizzare l'interfaccia utente One Tap

Con l'API HTML, One Tap viene sempre visualizzato al caricamento della pagina. Con il codice JavaScript

hai la possibilità di controllare quando viene visualizzata l'interfaccia utente di One Tap. Tieni presente che l'UI di One Tap potrebbe non essere sempre visualizzata dopo l'attivazione dell'API per alcuni motivi descritti di seguito.

Non provare a mostrare solo l'interfaccia utente One Tap su un evento di clic su un pulsante. L'UI di One Tap potrebbe non essere visualizzata per i motivi sopra indicati e l'esperienza utente potrebbe essere interrotta perché non viene mostrato nulla dopo l'azione dell'utente. In caso di clic su un pulsante:

Consigliato

  • Mostra la finestra di dialogo di accesso con password e pulsante Accedi con Google e chiama contemporaneamente l'API One Tap. In questo modo, agli utenti viene sempre offerto un metodo di accesso al tuo sito web.

Sconsigliato

  • Se offri un solo tocco, gli utenti potrebbero riscontrare problemi di accesso se la funzionalità One Tap non è visualizzata.
  • Utilizzo di un callback dello stato dell'interfaccia utente per mostrare un'altra UI se One Tap non viene visualizzato. Questa opzione non è consigliata perché il callback dello stato dell'interfaccia utente potrebbe non funzionare bene con la gestione delle credenziali federate in una release futura.

One Tap sui browser ITP

A causa della tecnologia Intelligent Tracking Prevention (ITP), la normale esperienza utente One Tap non funziona sui browser ITP, ad esempio Chrome su iOS, Safari e Firefox. Su questi browser viene invece fornita un'esperienza utente diversa che inizia con una pagina di benvenuto.

Se vuoi, puoi disattivare l'UX di One Tap sui browser ITP. Per ulteriori dettagli, consulta Assistenza One Tap sui browser ITP.

Non è possibile abilitare questa UX sui browser non ITP, ad esempio Chrome su Android/macOS/Linux ed Edge.

Annulla la richiesta se l'utente fa clic altrove

Per impostazione predefinita, la richiesta One Tap si chiude automaticamente se l'utente fa clic al di fuori della richiesta. Se vuoi, questo comportamento può essere modificato.

Ti consigliamo di tenere aperto il prompt One Tap sul Web desktop, poiché le dimensioni dello schermo sono sufficientemente grandi.

Modificare la posizione dell'UX di One Tap

Sul Web desktop, puoi modificare la posizione del messaggio di One Tap. Tuttavia, questa funzionalità non è consigliata poiché non è supportata dalla gestione delle credenziali federata in una release futura.

Cambiare il contesto di accesso

One Tap dovrebbe far parte di un flusso UX più ampio sul tuo sito web. Per impostazione predefinita, l'UI di One Tap viene utilizzata all'interno di un contesto di accesso. La lingua dell'interfaccia utente contiene parole particolari, ad esempio "accedi". Puoi modificare l'attributo di contesto per creare un insieme di parole diverso. Puoi selezionare una delle intestazioni One Tap più adatta al tuo flusso UX.

Contesto
signin "Accedi con Google"
signup "Registrati con Google"
use "Utilizza con Google"

Stato dell'interfaccia utente di Ascolta su One Tap

Per un'integrazione perfetta nel tuo flusso UX più ampio, One Tap può inviarti una notifica quando lo stato dell'interfaccia utente cambia. Tuttavia, questa funzionalità non è supportata nelle future release della gestione delle credenziali federate.

Un tocco nei sottodomini

Per impostazione predefinita, il raffreddamento One Tap e altri stati sono monitorati in base all'origine. Se il tuo sito web mostra One Tap in più sottodomini, devi indicarlo nel codice API.

One Tap nelle pagine HTML statiche

Per impostazione predefinita, la libreria GIS presuppone che le pagine web vengano generate in modo dinamico. Il server HTTP verifica lo stato di accesso dell'utente durante la generazione del codice HTML.

  • Se nessun utente ha eseguito l'accesso, è necessario includere il codice HTML One Tap nella pagina risultante, in modo da attivare One Tap per consentire agli utenti di accedere al tuo sito web.
  • Se gli utenti hanno già eseguito l'accesso, il codice HTML One Tap non deve essere incluso nella pagina visualizzata.

In questo caso, è responsabilità del server web aggiungere o rimuovere il codice dell'API HTML One Tap.

Il codice dell'API HTML One Tap può funzionare in un altro modo, progettato per i siti web che ospitano molti contenuti HTML statici. Puoi sempre includere il codice API HTML di One Tap nelle tue pagine HTML statiche e specificare il nome del cookie della sessione utilizzato nel tuo sito web.

  • Se il cookie della sessione non esiste, viene attivato il flusso One Tap.
  • Se il cookie della sessione esiste, il flusso One Tap viene ignorato.

In questo caso, l'attivazione o meno del flusso One Tap dipende dallo stato del cookie della sessione, anziché dall'esistenza del codice API HTML One Tap nella tua pagina web.

Integrazione lato server

Dopo One Tap, l'accesso automatico o il flusso UX del pulsante Accedi con Google viene emesso un token ID che viene condiviso con il tuo sito web. Per autenticare l'utente, sono necessarie alcune modifiche lato server per ricevere e convalidare il token ID.

Considerazioni relative all'esperienza utente

Normalmente, devi aggiungere un endpoint HTTP nella tua origine per gestire le risposte sul lato server. I seguenti fattori potrebbero influire sull'esperienza utente risultante.

L'esperienza utente effettiva è descritta di seguito.

  1. Per il reindirizzamento del pulsante Accedi con Google: la modalità UX:

    • Indipendentemente dal fatto che venga utilizzata l'API HTML o l'API JavaScript, devi impostare l'URI di accesso. È impossibile utilizzare una funzione di callback JavaScript per gestire la risposta, poiché gli utenti sono già stati reindirizzati dalla pagina web.
    • Riepilogo UX: dopo aver fatto clic sul pulsante Accedi con Google, gli utenti visualizzano un reindirizzamento a pagina intera a una UI di Google per la selezione e l'approvazione della sessione. Al termine, viene inviato un POST a pagina intera all'URI di accesso specificato.

  2. Per la modalità UX popup del pulsante One Tap o Accedi con Google, se si utilizza l'API JavaScript o l'API HTML e viene fornita una funzione di callback JavaScript:

    • Le risposte di autenticazione vengono restituite alla funzione di callback JavaScript.
    • Riepilogo UX: sopra la pagina web viene visualizzato il messaggio One Tap o una finestra popup. Dopo che gli utenti hanno completato l'esperienza utente nella finestra popup o nella richiesta per la selezione e l'approvazione della sessione, la funzione di callback JavaScript riceve le risposte. L'esperienza utente successiva viene stabilita in base al modo in cui la funzione di callback invia le risposte al server.

  3. In caso contrario (l'API HTML con l'uso delle maiuscole nell'URI di accesso):

    • Le risposte di autenticazione vengono inviate all'URI di accesso.
    • Riepilogo UX: sopra la pagina web viene visualizzato il messaggio One Tap o una finestra popup. Dopo che gli utenti hanno completato l'esperienza utente nella richiesta o nella finestra popup per la selezione e l'approvazione della sessione, le risposte di autenticazione vengono inviate utilizzando un invio di POST a pagina intera all'URL di accesso specificato.

Ti consigliamo di utilizzare un modo coerente per inviare le risposte One Tap e le risposte del pulsante Accedi con Google.

Considerazioni sulla sicurezza

Per prevenire gli attacchi di falsificazione di richieste tra siti:

  • Per i post-invio attivati dalla libreria JavaScript del client del servizio Google Identity, puoi utilizzare il pattern Double-submit-cookie integrato. Per ulteriori dettagli, consulta Verificare il token ID di Google sul lato server.
  • Per l'invio alla tua origine utilizzando XmlHttpRequest, puoi utilizzare l'intestazione HTTP personalizzata o altre misure di sicurezza approvate dal tuo team di sicurezza.

Per verificare i token ID nelle risposte di autenticazione, ti consigliamo vivamente di utilizzare una libreria client dell'API di Google per la tua piattaforma o una libreria JWT per uso generico.

Domande frequenti

  • Il pulsante One Tap e Accedi con Google è disponibile nelle WebView?

    No. Per motivi di sicurezza, gli utenti non devono aggiungere sessioni Google alle WebView. Di conseguenza, GIS è disattivato nelle WebView, in quanto non è presumibile che ci siano sessioni Google.

  • Posso utilizzare il mio pulsante Accedi con Google? No. Con il flusso lato server OAuth o la versione precedente della libreria JavaScript Accedi con Google, le parti in base agli utenti potevano usare le linee guida per il branding dell'accesso per creare le proprie versioni dei pulsanti Accedi con Google.

    Tuttavia, Accedi con Google ha rimosso questa funzionalità. Tutti i pulsanti Accedi con Google devono essere generati dalla libreria JavaScript dei Servizi di identità Google. I motivi di questa modifica sono due.

    • Alcune parti affidabili non hanno rispettato le linee guida, il che ha causato incoerenza dei pulsanti Accedi con Google sui siti web.
    • Se lo generi in base alla libreria, non devi apportare alcuna modifica quando le linee guida per il branding per l'accesso cambiano.

    Per applicare questa regola, la libreria JavaScript espone solo un'API per il rendering di un pulsante, ma non l'API per avviare il flusso di accesso.

  • Cosa succede se il mio sito web attiva solo One Tap ma non il pulsante Accedi con Google?

    Ti consigliamo di utilizzare sia il pulsante One Tap sia il pulsante Accedi con Google sul tuo sito web. A causa di un raffreddamento esponenziale, One Tap potrebbe non essere visualizzato ogni volta. Quando gli utenti vogliono davvero accedere al tuo sito web con i loro Account Google, possono andare alla finestra di dialogo di accesso principale e utilizzare il pulsante Accedi con Google. Se l'accesso viene eseguito con il pulsante Accedi con Google, verrà cancellato lo stato di raffreddamento One Tap in modo che One Tap possa essere visualizzato per l'accesso successivo. Altri flussi di pulsanti provenienti da Google non possono cancellare gli stati di raffreddamento One Tap, perché si trovano in programmi binari JavaScript diversi.

    Se il tuo sito web attiva solo One Tap ma non il pulsante Accedi con Google, potresti notare un calo del rendimento del flusso One Tap, poiché gli stati di attesa esponenziale non vengono cancellati in tempo.

  • Quando viene analizzato il mio codice API HTML? Posso modificare il mio codice API HTML in un secondo momento?

    La libreria JavaScript dei Servizi di identità Google analizza ed esegue il codice API HTML nell'evento di caricamento della libreria JavaScript o nell'evento DomContentLoaded, a seconda dell'evento che si verifica dopo.

    • Se l'evento DomContentLoaded viene attivato al caricamento della libreria JavaScript, il codice API HTML viene analizzato ed eseguito immediatamente.
    • In caso contrario, la libreria JavaScript aggiunge un listener per l'evento DomContentLoaded. Quando viene attivato, il listener analizza ed esegue il codice API HTML.

    Tieni inoltre presente che l'analisi e l'esecuzione del codice API HTML sono una tantum.

    • Dopo l'analisi e l'esecuzione, eventuali modifiche successive al codice API HTML vengono ignorate.
    • Non esiste un'API per gli sviluppatori per attivare il processo di analisi o esecuzione.