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 necessari 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 soltanto quando gli utenti hanno eseguito l'accesso a Google prima di caricare le pagine web. Questo passaggio è facoltativo per la procedura del pulsante Accedi con Google, poiché agli utenti viene chiesto di accedere a Google quando viene premuto il pulsante.

  2. Gli utenti navigano nelle tue pagine web dove sono incorporati il pulsante One Tap, Accesso automatico o Accedi con Google.

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

    • Seleziona una sessione Google attiva per continuare.
    • Ottieni il consenso degli utenti finali per condividere le informazioni del profilo con il tuo sito web, se non lo hanno ancora fatto.

    Se nel browser è attiva una sola sessione Google,

    • One Tap seleziona automaticamente l'unica sessione e salta 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 in caso di necessità.

    Se l'Account Google selezionato non è mai stato utilizzato con il tuo sito web o 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. Un token web JSON (noto anche come token ID) credenziale contenente il nome, l'email e l'immagine del profilo dell'utente viene condiviso utilizzando un gestore di callback JavaScript o un invio post al tuo servizio di backend.

    Lo scopo di restituire i token ID al gestore callback JavaScript sul lato client non è quello di decodificarli nel codice JavaScript, ma di inviarli al tuo server nel modo che preferisci. Un buon esempio è l'utilizzo di XmlHttpRequest per evitare il ricaricamento della pagina causato dall'invio.

  5. Sul lato server, le credenziali JWT rilasciate da Google vengono convalidate e utilizzate 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 al momento dell'accesso, in cui sai che l'utente si è autenticato correttamente e ha eseguito l'accesso al proprio Account Google. Gli utenti possono rimanere collegati, uscire o passare a un altro Account Google mantenendo una sessione attiva con l'accesso sul tuo sito web.

In sintesi, come 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 in precedenza, potresti dover integrare anche l'API Authorization se il tuo sito deve accedere alle API e ai servizi Google per conto di utenti autenticati. Mentre l'autenticazione fornisce al tuo sito token ID per autenticare gli utenti, l'autorizzazione fornisce al tuo sito token di accesso (separati) e autorizzazioni per utilizzare le API e i servizi Google. Consulta la sezione Autorizzazione per il Web per ulteriori informazioni.

Separazione UX per autenticazione e autorizzazione

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

Se in passato il tuo sito web ha richiesto contemporaneamente token di autenticazione e autorizzazione, quando utilizzi la libreria JavaScript dei Servizi di identità Google devi regolare la tua UX in modo da separare il momento di autenticazione da quello di autorizzazione.

  • Al momento dell'autenticazione, il tuo sito web può integrarsi con 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 Google.

Per una transizione UX senza problemi e una riduzione della complessità, è prassi comune dividere il processo in due passaggi separati.

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

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

API HTML e API JavaScript a confronto

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

Con l'API HTML, hai più funzioni integrate. Ad esempio,

  • Rendering One Tap o del pulsante Accedi con Google al caricamento della pagina.
  • Invia la credenziale restituita al tuo endpoint lato server, che è specificato dall'attributo data-login_uri, dopo aver completato l'UX con un tocco, accesso automatico o popup di pulsanti/reindirizzamento.
  • Previeni gli attacchi CSRF inviando i cookie due volte.
  • Utilizza il generatore di codice per generare il codice HTML, poi copialo nelle tue 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 è l'utilizzo di un metodo XmlHttpRequest per inviare la credenziale restituita al server, in modo da evitare il ricaricamento della pagina causato dall'invio predefinito dei dati.

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

  • Rendering One Tap e pulsante Accedi con Google in un secondo momento. Ad esempio, dopo che gli utenti selezionano Login (Accedi) dal menu.
  • Chiamata all'API più volte. Ad esempio, il pulsante Accedi con Google deve essere visualizzato ogni volta che viene visualizzata la finestra di dialogo di accesso.
  • Generazione dinamica delle pagine HTML, che rende difficile incorporare il codice di chiamata API al loro interno.
  • Caricherai la libreria JavaScript dei Servizi di identità Google in un secondo momento.

Il codice dell'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 per ultimo. Dovresti 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 inizializzare la pagina o per il rendering con One Tap e pulsanti. Verifica che nel codice, sia HTML che JavaScript, non si sovrappongano. Tieni presente quanto riportato di seguito:

  • 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>.
  • Stai utilizzando 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 One Tap e pulsante; non hanno API HTML corrispondenti:

Considerazioni sul pulsante Accedi con Google

Popup e reindirizzamento

La specifica OAuth 2.0 prende in considerazione il reindirizzamento HTTP, ma non dispone di indicazioni sul rendering delle finestre di dialogo popup. L'esperienza utente popup, in particolare sul web desktop, può fornire una migliore esperienza utente agli utenti finali. Questo perché gli utenti non vengono reindirizzati dalle pagine di terze parti e una finestra popup simile a una finestra di dialogo offre un'esperienza contestuale per la concessione delle autorizzazioni.

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

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

Esistono alcune differenze tra il flusso di reindirizzamento del pulsante Accedi con Google e il flusso di reindirizzamento OAuth.

  • Il flusso di reindirizzamento del pulsante Accedi con Google utilizza sempre il metodo POST per inviare la credenziale al tuo server web, mentre il reindirizzamento OAuth normalmente 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 passare dalla 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 tuo client nella console API di Google.

Personalizzazione del pulsante

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

Per attivare il flusso dei pulsanti Accedi con Google, devi solo 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 di rendering dei pulsanti 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 prima generare il codice HTML, quindi copiarlo nei campi corrispondenti dell'API JavaScript.

Non esiste un'API che consenta 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. Per ulteriori dettagli, consulta la 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 visualizzato in un iframe del dominio accounts.google.com. Il caricamento di un iframe può richiedere molto tempo su una rete lenta. Per mitigare questo problema di latenza, il rendering dei pulsanti viene eseguito in due passaggi, come segue:

  1. Viene visualizzata una versione di un pulsante in linea nella struttura DOM del tuo sito web. È solo un pulsante di testo, non è possibile usare informazioni personalizzate. Lo scopo è consentire agli utenti di vedere il pulsante il prima possibile.
  2. A Google viene inviata una richiesta iframe 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 del flusso del pulsante Accedi con Google.

  • Carica la libreria JavaScript dei Servizi di identità Google il prima possibile. Considera l'idea di 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 prima visualizzare il pulsante Accedi con Google in un elemento nascosto e poi renderlo visibile dopo che l'utente seleziona Accedi dal menu.

Considerazioni One Tap

Accesso automatico

L'accesso automatico annullabile offre i seguenti vantaggi.

  • Questa azione potrebbe migliorare la percentuale di accesso salvando un'azione utente.
  • A differenza dell'accesso automatico fornito dalla precedente libreria JavaScript deprecata Accedi con Google, gli utenti vedono sempre alcune UI quando viene eseguito l'accesso automatico, il che fornisce loro il contesto relativo e perché hanno effettuato l'accesso al tuo sito web. Gli utenti possono anche annullare l'abbonamento, se lo desiderano.
  • Seleziona automaticamente l'account utilizzato in precedenza dall'utente, il che potrebbe impedirgli di creare account duplicati sul tuo sito web.

Se abilitare l'accesso automatico è una decisione che devi prendere in base ai requisiti aziendali e UX del tuo sito web. Soprattutto se la maggior parte delle disconnessioni dal tuo sito web sono causate dal timeout della sessione anziché da scelte esplicite dell'utente, l'accesso automatico può essere un buon modo per consentire agli utenti di recuperare lo stato della sessione.

Quando visualizzare l'UI di One Tap

Con l'API HTML, One Tap viene sempre visualizzato al caricamento della pagina. Con l'API JavaScript, puoi controllare quando viene visualizzata la UI One Tap. Tieni presente che la UI One Tap potrebbe non essere sempre visualizzata dopo che è stata richiamata l'API per alcuni motivi descritti di seguito.

  • Nessuna sessione Google attiva nel browser.
  • Tutte le sessioni Google attive sono disattivate.
  • È in corso il recupero.

Non provare a visualizzare solo l'UI One Tap per un evento di clic su un pulsante. L'interfaccia utente di One Tap potrebbe non essere visualizzata per i motivi illustrati sopra e gli utenti potrebbero avere una UX non funzionante, in quanto non viene visualizzato nulla dopo l'azione dell'utente. In caso di evento di clic su un pulsante:

Consigliato

  • Mostra la finestra di dialogo di accesso con accesso tramite password e il pulsante Accedi con Google e chiama l'API One Tap contemporaneamente. Ciò garantisce che agli utenti sia sempre offerto un metodo di accesso per il tuo sito web.

Opzione non consigliata

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

Un tocco sui browser ITP

A causa della soluzione Intelligent Tracking Prevention (ITP), la normale UX di One Tap non funziona sui browser ITP, come Chrome su iOS, Safari e Firefox. Su questi browser viene invece fornita una UX diversa che inizi con una pagina di benvenuto.

Se vuoi, l'UX di One Tap sui browser ITP può essere disattivata. Per ulteriori dettagli, consulta l'articolo Supporto di One Tap sui browser ITP.

Non c'è modo di abilitare questa UX su browser non ITP, come Chrome su Android/macOS/Linux ed Edge.

Annulla la richiesta se l'utente fa clic per uscire

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, perché le dimensioni dello schermo sono sufficientemente grandi.

Cambiare la posizione dell'esperienza utente con One Tap

Sul web da computer, puoi modificare la posizione della richiesta One Tap. Tuttavia, questa funzionalità non è consigliata poiché non sarà supportata dalla gestione delle credenziali federate in una release futura.

Modificare il contesto di accesso

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

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

Stato UI Ascolta con One Tap

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

Un tocco per i sottodomini

Per impostazione predefinita, il cooldown e gli altri stati di One Tap vengono monitorati in base all'origine. Se il tuo sito web visualizza 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 controlla lo stato di accesso dell'utente quando genera il codice HTML.

  • Se nessun utente ha eseguito l'accesso, il codice HTML One Tap dovrebbe essere incluso 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 API HTML One Tap può funzionare in altro modo, ad esempio per i siti web che ospitano molti contenuti HTML statici. Puoi sempre includere il codice dell'API One Tap HTML nelle tue pagine HTML statiche e specificare il nome del cookie di sessione utilizzato nel tuo sito web.

  • Se il cookie di sessione non esiste, viene attivato il flusso One Tap.
  • Se il cookie di sessione esiste, il flusso One Tap viene saltato.

In questo caso, l'attivazione del flusso One Tap è controllata dallo stato dei cookie della sessione, anziché dall'esistenza del codice dell'API One Tap HTML nella pagina web.

Integrazione lato server

Dopo aver completato il flusso UX con One Tap, l'accesso automatico o il 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 possono avere un impatto sull'UX risultante.

L'esperienza utente effettiva che ottieni è descritta di seguito.

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

    • 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 fuori dalla tua pagina web.
    • Riepilogo dell'esperienza utente: 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 del popup del pulsante Accedi con Google o One Tap o Accedi con Google, se si utilizza l'API JavaScript oppure si utilizza l'API HTML e viene fornita una funzione di callback JavaScript:

    • Le risposte auth vengono restituite alla funzione callback JavaScript.
    • Riepilogo dell'esperienza utente: il prompt One Tap o una finestra popup vengono mostrati sopra la pagina web. Dopo che gli utenti hanno completato l'esperienza utente nel prompt o nella finestra popup per la selezione e l'approvazione della sessione, la funzione di callback di JavaScript riceve le risposte. La successiva UX viene decisa dal modo in cui la funzione di callback invia le risposte al tuo server.

  3. Altrimenti (l'API HTML con il caso dell'URI di accesso):

    • Le risposte di autorizzazione vengono inviate all'URI di accesso.
    • Riepilogo UX: il prompt One Tap o una finestra popup vengono mostrati sopra la pagina web. Dopo che gli utenti hanno completato l'esperienza utente nel prompt o nella finestra popup per la selezione e l'approvazione della sessione, le risposte per l'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 l'invio successivo attivato dalla libreria JavaScript del client del servizio di identità Google, puoi utilizzare il pattern integrato integrato per double-submit-cookie. Per ulteriori dettagli, consulta Verificare il token ID Google sul lato server.
  • Per l'invio alla tua origine tramite un XmlHttpRequest, puoi utilizzare l'intestazione HTTP personalizzata o altre misure di sicurezza approvate dal 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 generica.

Domande frequenti

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

    No. Per motivi di sicurezza, gli utenti non devono aggiungere sessioni Google in WebView. Pertanto, i GIS vengono disattivati in WebView, in quanto non è prevista la presenza di sessioni Google.

  • Posso utilizzare il mio pulsante Accedi con Google? No. Con il flusso lato server OAuth o con la libreria JavaScript Accedi con Google della versione precedente, le parti erano in grado di utilizzare le linee guida per il branding relative all'accesso con Google 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 questo cambiamento sono due.

    • Alcune parti coinvolte non hanno rispettato le linee guida, il che genera un'incoerenza dei pulsanti Accedi con Google tra i vari siti web.
    • Poiché la generazione avviene tramite la libreria, non devi apportare alcuna modifica quando cambiano le linee guida per il branding per l'accesso.

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

  • Cosa succede se il mio sito web abilita solo un tocco, ma non il pulsante Accedi con Google?

    Ti consigliamo di utilizzare sia One Tap sia il pulsante Accedi con Google sul tuo sito web. A causa del raffreddamento esponenziale, One Tap potrebbe non essere visualizzato ogni volta. Quando gli utenti vogliono davvero accedere al tuo sito web con i propri Account Google, possono andare alla finestra di dialogo di accesso principale e accedere con il pulsante Accedi con Google. Un accesso riuscito con il pulsante Accedi con Google cancellerà lo stato di attesa di One Tap in modo che One Tap possa essere visualizzato per l'accesso successivo. Altri flussi di pulsanti da Google non possono cancellare gli stati di raffreddamento di One Tap, poiché si trovano in file binari JavaScript diversi.

    Se il tuo sito web attiva solo One Tap, ma non il pulsante Accedi con Google, potresti notare un calo delle prestazioni per il flusso One Tap, perché gli stati di raffreddamento esponenziale non vengono cancellati in tempo.

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

    La libreria JavaScript dei Servizi di identità Google analizza ed esegue il codice dell'API HTML nell'evento di caricamento della libreria JavaScript o nell'evento DomContentLoaded, a seconda di quale delle due date è più recente.

    • Se l'evento DomContentLoaded viene attivato quando viene caricata la libreria JavaScript, il codice dell'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 esegui il codice API HTML.

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

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