Remarques sur l'intégration

Ce guide par étapes vous aide à prendre des décisions concernant tous les principaux problèmes d'intégration.

Se connecter avec Google de manière abstraite

Voici la procédure générale à suivre par les utilisateurs pour se connecter / s'inscrire sur votre site Web.

  1. Les utilisateurs se connectent à un site Web Google.

    Pour que Se connecter avec Google fonctionne, une session Google active doit être ouverte dans le navigateur. One Tap et la connexion automatique ne se déclenchent que lorsque les utilisateurs se sont connectés à Google avant de charger vos pages Web. Cette étape est facultative pour le parcours du bouton Se connecter avec Google, car les utilisateurs sont invités à se connecter à Google lorsqu'ils appuient sur le bouton.

  2. Les utilisateurs parcourent vos pages Web sur lesquelles les boutons One Tap, Connexion automatique ou Se connecter avec Google sont intégrés.

  3. Les utilisateurs interagissent avec le bouton One Tap, le bouton Se connecter avec Google et les flux d'expérience utilisateur suivants afin de:

    • Sélectionnez une session Google active pour continuer.
    • Obtenez le consentement des utilisateurs finaux pour partager les informations de profil avec votre site Web, s'ils ne l'ont pas encore fait.

    Lorsqu'il n'y a qu'une seule session Google active dans le navigateur :

    • Le mode "Un appui" sélectionne automatiquement la seule session et ignore ainsi la page de sélection du compte.
    • Le bouton Se connecter avec Google reste sur la page de sélection du compte, ce qui permet aux utilisateurs d'ajouter une session Google si nécessaire.

    Si le compte Google sélectionné n'a jamais été utilisé avec votre site Web ou si l'autorisation a été révoquée, une page de consentement s'affiche.

    Écran de consentement du bouton "Se connecter avec Google"

    Une fois l'approbation obtenue, Google enregistre la décision afin de passer la page de consentement la prochaine fois.

  4. Un identifiant de jeton Web JSON (également appelé jeton d'ID) contenant le nom, l'adresse e-mail et la photo de profil de l'utilisateur est partagé à l'aide d'un gestionnaire de rappel JavaScript ou d'un envoi de post à votre service backend.

    Le but de renvoyer des jetons d'ID au gestionnaire de rappel JavaScript côté client n'est pas de les décoder dans le code JavaScript, mais de les envoyer à votre serveur à votre manière. Un bon exemple est d'utiliser un XmlHttpRequest pour éviter le rechargement de la page causé par l'envoi du post.

  5. Côté serveur, les identifiants JWT émis par Google sont validés et consommés pour créer un compte ou établir une session authentifiée sur votre site Web.

    Vous gérerez l'état de connexion des utilisateurs sur votre propre site Web.

    L'état de connexion du compte Google de l'utilisateur et votre application sont indépendants l'un de l'autre, sauf au moment de la connexion, lorsque vous savez que l'utilisateur s'est authentifié et est connecté à son compte Google. Les utilisateurs peuvent rester connectés, se déconnecter ou passer à un autre compte Google tout en conservant une session active et connectée sur votre site Web.

En résumé, comme la connexion par mot de passe, S'inscrire avec Google offre un autre moyen d'authentifier les utilisateurs sur le Web. La fonctionnalité Se connecter avec Google ne fournit aucune fonctionnalité de gestion de session sur votre site Web après l'authentification.

Accéder aux API et services Google

Bien que vous ayez intégré l'API d'authentification, comme décrit précédemment, vous devrez peut-être également intégrer l'API d'autorisation si votre site doit accéder aux API et services Google pour le compte d'utilisateurs authentifiés. Alors que l'authentification fournit à votre site des jetons d'ID pour authentifier les utilisateurs, l'autorisation fournit à votre site des jetons d'accès (distincts) et des autorisations pour utiliser les API et services Google. Pour en savoir plus, consultez la section Autoriser pour le Web.

Séparation de l'expérience utilisateur pour l'authentification et l'autorisation

Si votre site Web doit appeler à la fois les API d'authentification et d'autorisation, vous devez les appeler séparément à différents moments. Consultez Séparer les moments d'authentification et d'autorisation.

Si votre site Web a demandé des jetons d'authentification et d'autorisation ensemble par le passé, lorsque vous utilisez la bibliothèque JavaScript Google Identity Services, vous devez ajuster votre expérience utilisateur pour séparer le moment de l'authentification du moment de l'autorisation.

  • Au moment de l'authentification, votre site Web peut intégrer One Tap, la connexion automatique ou le bouton "Se connecter avec Google" pour permettre aux utilisateurs de se connecter ou de s'inscrire sur votre site Web.
  • Au moment de l'autorisation, votre site Web peut appeler l'API d'autorisation pour obtenir les autorisations et les jetons permettant d'accéder aux API ou services Google.

Pour une transition UX fluide et une réduction de la complexité, il est courant de diviser le processus en deux étapes distinctes.

  1. Refactorisez l'expérience utilisateur pour séparer les moments d'authentification et d'autorisation.

  2. Migrez vers la bibliothèque JavaScript Google Identity Services.

API HTML par rapport à l'API JavaScript

Vous pouvez utiliser l'API HTML ou l'API JavaScript pour intégrer le bouton "Un appui", "Connexion automatique" ou "Se connecter avec Google" à vos pages Web.

L'API HTML vous offre plus de fonctionnalités intégrées. Par exemple,

  • Affichage de One Tap ou du bouton "Se connecter avec Google" au chargement de la page.
  • Envoyez les identifiants renvoyés à votre point de terminaison côté serveur, spécifié par l'attribut data-login_uri, une fois l'expérience utilisateur de l'authentification par appui, de la connexion automatique ou du pop-up/redirection du bouton terminée.
  • Prévenez les attaques CSRF à l'aide de double-submit-cookie.
  • Utilisez le générateur de code pour générer le code HTML, puis copiez-le dans vos pages HTML.

Avec l'API HTML, vous pouvez également écrire du code JavaScript pour personnaliser le comportement.

  • Vous pouvez écrire votre propre gestionnaire de rappel, puis définir le nom de la fonction sur l'attribut data-callback. Un bon exemple consiste à utiliser un XmlHttpRequest pour envoyer les identifiants renvoyés à votre serveur, afin d'éviter le rechargement de la page causé par l'envoi par défaut de la publication.

L'API JavaScript vous offre plus de flexibilité dans certains scénarios.

  • Affichage de One Tap et du bouton "Se connecter avec Google" ultérieurement. Par exemple, après que les utilisateurs ont sélectionné Se connecter dans le menu.
  • Appeler l'API plusieurs fois Par exemple, le bouton "Se connecter avec Google" doit être affiché chaque fois que la boîte de dialogue de connexion s'affiche.
  • Générer vos pages HTML de manière dynamique, ce qui rend difficile l'intégration de code d'appel d'API.
  • Vous chargez la bibliothèque JavaScript Google Identity Services à un stade beaucoup plus tardif.

Le code d'API HTML ne peut être appelé qu'une seule fois, soit lors de l'événement de chargement de la page, soit lors de l'événement de chargement de la bibliothèque JavaScript Google Identity Services, selon la date la plus tardive. Vous devez utiliser l'API JavaScript si le comportement de l'API HTML ne répond pas à vos attentes.

N'utilisez pas l'API HTML avec l'API JavaScript sur la même page Web pour initialiser la page ni pour le rendu d'un appui et d'un bouton. Vérifiez les endroits où votre code HTML et JavaScript peuvent se chevaucher. Veuillez noter les points suivants :

  • Vous utilisez l'API HTML si un ou plusieurs des éléments de <div id='g_id_onload' ... ><id> ou <div class='g_id_signin' ...></div> existent dans votre code HTML.
  • Vous utilisez l'API JavaScript si une ou plusieurs des méthodes de initialize(), prompt() ou render() sont appelées dans votre code JavaScript, qu'elles soient intégrées ou chargées à partir d'un fichier JavaScript distinct.

Les API JavaScript suivantes peuvent être utilisées indépendamment de l'initialisation ou du rendu d'un bouton et d'un appui unique. Elles n'ont pas d'API HTML correspondantes:

Consignes concernant le bouton "Se connecter avec Google"

Cette section présente les éléments à prendre en compte pour intégrer le bouton Se connecter avec Google à votre site Web.

Pop-up ou redirection

La spécification OAuth 2.0 prend en compte la redirection HTTP, mais ne fournit aucune recommandation sur l'affichage des boîtes de dialogue pop-up. L'expérience utilisateur des pop-ups, en particulier sur le Web pour ordinateur, peut être meilleure pour les utilisateurs finaux. En effet, les utilisateurs ne sont pas redirigés vers d'autres pages tierces, et une fenêtre pop-up semblable à une boîte de dialogue offre une expérience dans le contexte de l'autorisation.

Avec l'expérience utilisateur du pop-up, le fournisseur d'identité doit s'appuyer sur des canaux de communication inter-origine côté client pour transmettre les réponses OAuth de la fenêtre pop-up, où s'affiche la page de consentement du fournisseur d'identité, à la fenêtre principale, où s'affiche la page tierce. Normalement, des codes JavaScript sont requis des deux côtés pour envoyer et recevoir la réponse OAuth entre les fenêtres.

Le bouton "Se connecter avec Google" est compatible avec l'expérience utilisateur du pop-up et de la redirection. Par défaut, l'expérience utilisateur du pop-up est utilisée. Vous pouvez modifier l'expérience utilisateur en définissant l'attribut data-ux_mode.

Il existe quelques différences entre le flux de redirection du bouton Se connecter avec Google et le flux de redirection OAuth.

  • Le flux de redirection du bouton Se connecter avec Google utilise toujours la méthode POST pour envoyer les identifiants à votre serveur Web, tandis que la redirection OAuth utilise normalement la méthode GET.
  • Les paramètres envoyés par le flux de redirection du bouton "Se connecter avec Google" sont différents de ceux du flux de redirection OAuth.

Pour les développeurs qui utilisent l'API HTML, quelle que soit l'expérience utilisateur utilisée, les identifiants sont toujours envoyés à data-login_uri avec la méthode POST et les mêmes paramètres. Vous pouvez ainsi changer de mode d'expérience utilisateur sans modifier le code. Pour l'expérience utilisateur de redirection, data-login_uri doit être ajouté aux URI de redirection autorisés de votre client dans la console d'API Google.

Personnalisation des boutons

L'utilisation de votre propre bouton n'est pas autorisée. Il n'existe aucune API permettant d'initialiser un flux de boutons de manière programmatique.

Pour activer le flux du bouton Se connecter avec Google, il vous suffit d'afficher un ou plusieurs boutons Se connecter avec Google sur vos pages Web. Le parcours de bouton est lancé et géré de manière transparente lorsque les utilisateurs cliquent sur ces boutons.

L'API de rendu des boutons vous permet de personnaliser l'apparence du bouton "Se connecter avec Google". Nous vous recommandons d'utiliser le générateur de code pour concevoir vos boutons de manière interactive. Même si vous utilisez l'API JavaScript, vous pouvez d'abord générer le code HTML, puis le copier dans les champs correspondants de l'API JavaScript.

Aucune API ne permet aux sites Web de contrôler si les informations personnalisées doivent être utilisées pour afficher les boutons. Les boutons personnalisés s'affichent si toutes les conditions sont remplies. Pour en savoir plus, consultez la section Comprendre le bouton Personnalisé.

Vous pouvez placer plusieurs boutons sur une même page Web. Le générateur de code ne peut créer qu'un seul bouton à la fois. Vous pouvez l'exécuter plusieurs fois et copier le code <div class='g_id_signin' ...></div> généré dans la page Web.

Bonnes pratiques d'affichage des boutons

Pour des raisons de confidentialité, le bouton personnalisé s'affiche dans une iFrame du domaine accounts.google.com. Le chargement d'un iframe peut être long sur un réseau lent. Pour atténuer ce problème de latence, les boutons sont affichés en deux étapes, comme suit:

  1. Une version de bouton intégré est affichée dans l'arborescence DOM de votre site Web. Il s'agit simplement d'un bouton de texte. Aucune information personnalisée ne peut être utilisée. L'objectif est de permettre aux utilisateurs de voir le bouton dès que possible.
  2. Une requête d'iframe est envoyée à Google pour charger l'iframe du bouton, qui peut contenir des informations personnalisées. Une fois l'iFrame du bouton chargée, le bouton de la version intégrée est supprimé.

Voici quelques bonnes pratiques pour réduire la latence d'affichage du bouton de connexion avec Google.

  • Chargez la bibliothèque JavaScript Google Identity Services dès que possible. Pensez à charger la bibliothèque JavaScript avant certaines autres grandes bibliothèques, en particulier sur le Web mobile.

  • Si le bouton "Se connecter avec Google" ne s'affiche que lorsque l'utilisateur sélectionne Se connecter dans le menu. Vous pouvez d'abord afficher le bouton Se connecter avec Google dans un élément masqué, puis le rendre visible une fois que l'utilisateur a sélectionné Se connecter dans le menu.

Considérations concernant One Tap

Connexion automatique

La fonctionnalité de connexion automatique permet aux utilisateurs de se connecter à votre site Web sans cliquer sur l'invite "One Tap" s'ils ont déjà accordé une autorisation à votre site Web.

La connexion automatique annulable offre les avantages suivants.

  • Cela peut améliorer le taux de connexion en économisant une action utilisateur.
  • Contrairement à la connexion silencieuse fournie par la bibliothèque JavaScript Google Sign-In obsolète, les utilisateurs voient toujours une interface utilisateur lorsque la connexion automatique a lieu, ce qui leur donne le contexte de la raison et de la manière dont ils sont connectés à votre site Web. Les utilisateurs peuvent également résilier l'abonnement s'ils le souhaitent.
  • Il sélectionne automatiquement le compte que l'utilisateur utilisait auparavant, ce qui peut l'empêcher de créer des comptes en double sur votre site Web.

Vous devez décider d'activer ou non la connexion automatique en fonction de l'expérience utilisateur et des exigences métier de votre site Web. En particulier si la plupart des déconnexions de votre site Web sont dues à l'expiration de la session plutôt qu'à des choix explicites de l'utilisateur, la connexion automatique peut être un bon moyen pour vos utilisateurs de récupérer l'état de la session.

Quand afficher l'UI d'un appui

Avec l'API HTML, le bouton "One Tap" s'affiche toujours au chargement de la page. Avec l'API JavaScript, vous pouvez contrôler quand l'interface utilisateur One Tap s'affiche. Notez que l'UI One Tap ne s'affiche pas toujours après l'appel de l'API, pour les raisons suivantes.

N'essayez pas d'afficher uniquement l'UI One Tap lors d'un événement de clic sur un bouton. L'UI One Tap peut ne pas s'afficher pour les raisons indiquées, et l'expérience utilisateur peut être interrompue, car rien ne s'affiche après l'action de l'utilisateur. Lors d'un événement de clic sur un bouton:

Recommandé

  • Affichez votre boîte de dialogue de connexion avec la connexion par mot de passe et le bouton Se connecter avec Google, et appelez l'API One Tap en même temps. Cela garantit que les utilisateurs ont toujours une méthode de connexion disponible sur votre site Web.

Déconseillé

  • Si vous n'offrez que le mode "Un appui", les utilisateurs peuvent rencontrer des problèmes de connexion si ce mode n'est pas affiché.
  • Utilisation d'un appel de rappel d'état de l'UI pour afficher une autre UI si le mode Un Tap ne s'affiche pas. Cette approche n'est pas recommandée, car le rappel d'état de l'UI risque de ne pas fonctionner correctement avec la gestion des identifiants fédérés dans une prochaine version.

One Tap sur les navigateurs ITP

En raison de la fonctionnalité ITP (Intelligent Tracking Prevention), l'expérience utilisateur One Tap normale ne fonctionne pas sur les navigateurs ITP, tels que Chrome sur iOS, Safari et Firefox. Une expérience utilisateur différente commençant par une page de bienvenue est proposée sur ces navigateurs.

Si vous le souhaitez, vous pouvez désactiver l'expérience utilisateur One Tap sur les navigateurs ITP. Pour en savoir plus, consultez la section Compatibilité avec le paiement sans contact sur les navigateurs ITP.

Il n'existe aucun moyen d'activer cette expérience utilisateur sur les navigateurs autres que les navigateurs ITP, tels que Chrome sur Android/macOS/Linux et Edge.

Annuler l'invite si l'utilisateur clique ailleurs

Par défaut, l'invite de paiement sans contact se ferme automatiquement si l'utilisateur clique en dehors de l'invite. Vous pouvez modifier ce comportement si vous le souhaitez.

Nous vous recommandons de laisser l'invite de paiement sans contact ouverte sur le Web pour ordinateur, car la taille de l'écran est suffisante.

Modifier la position de l'expérience One Tap

Sur le Web pour ordinateur, vous pouvez modifier la position de l'invite avec un seul geste. Toutefois, cette fonctionnalité n'est pas recommandée, car elle ne sera pas prise en charge par la gestion des identifiants fédérés dans une prochaine version.

Modifier le contexte de connexion

Le paiement sans contact doit faire partie d'un parcours UX plus vaste sur votre site Web. Par défaut, l'UI One Tap est utilisée dans un contexte de connexion. Le langage de l'interface utilisateur contient des formulations particulières, telles que "Se connecter". Vous pouvez modifier l'attribut de contexte pour créer un autre ensemble de formulations. Vous pouvez sélectionner l'un des en-têtes One Tap qui convient le mieux à votre parcours UX.

Contexte
signin "Se connecter avec Google"
signup "S'inscrire avec Google"
use "Utiliser avec Google"

État de l'UI d'écoute avec One Tap

Pour s'intégrer parfaitement à votre parcours UX plus vaste, One Tap peut vous envoyer une notification lorsque l'état de l'UI change. Toutefois, cette fonctionnalité n'est pas prise en charge dans les futures versions de la gestion des identifiants fédérés.

Un appui sur les sous-domaines

Par défaut, le temps de pause du service One Tap et d'autres états sont suivis par origine. Si votre site Web affiche le mode Un Tap sur plusieurs sous-domaines, vous devez l'indiquer dans votre code API.

Un appui sur les pages HTML statiques

Par défaut, la bibliothèque SIG suppose que vos pages Web sont générées de manière dynamique. Votre serveur HTTP vérifie l'état de connexion de l'utilisateur lors de la génération du code HTML.

  • Si aucun utilisateur n'est connecté, le code HTML One Tap doit être inclus dans la page générée afin de déclencher One Tap et d'autoriser les utilisateurs à se connecter à votre site Web.
  • Si les utilisateurs sont déjà connectés, le code HTML One Tap ne doit pas être inclus dans la page générée.

Dans ce cas, c'est votre serveur Web qui est chargé d'ajouter ou de supprimer le code de l'API HTML One Tap.

Le code de l'API HTML One Tap peut fonctionner d'une autre manière, conçue pour les sites Web qui hébergent de nombreux contenus HTML statiques. Vous pouvez toujours inclure le code de l'API HTML One Tap dans vos pages HTML statiques et spécifier le nom du cookie de session utilisé sur votre site Web.

  • Si le cookie de session n'existe pas, le flux "One Tap" est déclenché.
  • Si le cookie de session existe, le flux One Tap est ignoré.

Dans ce cas, le déclenchement du flux One Tap est contrôlé par l'état du cookie de session, et non par l'existence du code d'API HTML One Tap sur votre page Web.

Intégration côté serveur

Une fois le flux d'expérience utilisateur One Tap, de connexion automatique ou du bouton "Se connecter avec Google" terminé, un jeton d'identité est émis et partagé avec votre site Web. Pour authentifier l'utilisateur, certaines modifications côté serveur sont requises pour recevoir et valider le jeton d'identification.

Considérations relatives à l'expérience utilisateur

Normalement, vous devez ajouter un point de terminaison HTTP dans votre propre origine pour gérer les réponses côté serveur. Les facteurs suivants peuvent avoir une incidence sur l'expérience utilisateur qui en résulte.

  • Indique si One Tap ou Se connecter avec Google est déclenché.
  • Indique si l'API HTML ou l'API JavaScript est utilisée.
  • Indique si l'URI de connexion ou la fonction de rappel JavaScript est utilisée pour gérer la réponse.

L'expérience utilisateur réelle est décrite comme suit.

  1. Pour le mode d'expérience utilisateur de redirection du bouton "Se connecter avec Google" :

    • Que vous utilisiez l'API HTML ou l'API JavaScript, vous devez définir l'URI de connexion. Il est impossible d'utiliser une fonction de rappel JavaScript pour gérer la réponse, car les utilisateurs ont déjà été redirigés depuis votre page Web.
    • Résumé de l'expérience utilisateur: après avoir cliqué sur le bouton "Se connecter avec Google", les utilisateurs sont redirigés vers une interface utilisateur Google pour sélectionner et approuver la session. Une fois cette opération effectuée, une POST pleine page est envoyée à l'URI de connexion que vous avez spécifié.

  2. Pour le mode d'expérience utilisateur du bouton "Se connecter avec Google" ou du pop-up "Un appui", si l'API JavaScript est utilisée ou si l'API HTML est utilisée et qu'une fonction de rappel JavaScript est fournie:

    • Les réponses d'authentification sont transmises à la fonction de rappel JavaScript.
    • Résumé de l'expérience utilisateur: L'invite One Tap ou une fenêtre pop-up s'affiche au-dessus de votre page Web. Une fois que les utilisateurs ont terminé l'expérience utilisateur dans l'invite ou la fenêtre pop-up pour la sélection et l'approbation de la session, la fonction de rappel JavaScript reçoit les réponses. L'expérience utilisateur ultérieure est déterminée par la manière dont votre fonction de rappel envoie les réponses à votre serveur.

  3. Dans le cas contraire (API HTML avec l'URI de connexion):

    • Les réponses d'authentification sont envoyées à l'URI de connexion.
    • Résumé de l'expérience utilisateur: l'invite One Tap ou une fenêtre pop-up s'affiche au-dessus de votre page Web. Une fois que les utilisateurs ont terminé l'expérience utilisateur dans l'invite ou la fenêtre pop-up pour la sélection et l'approbation de la session, les réponses d'authentification sont envoyées à l'URL de connexion que vous avez spécifiée à l'aide d'une soumission POST sur toute la page.

Nous vous recommandons d'utiliser une méthode cohérente pour envoyer les réponses du bouton One Tap et du bouton Se connecter avec Google.

Considérations de sécurité

Pour empêcher les attaques de falsification de requêtes intersites :

  • Pour l'envoi de post déclenché par la bibliothèque JavaScript cliente Google Identity Service, vous pouvez utiliser le modèle de double envoi de cookie intégré. Pour en savoir plus, consultez Valider le jeton d'ID Google côté serveur.
  • Pour l'envoi à votre propre origine à l'aide d'un XmlHttpRequest, vous pouvez utiliser l'en-tête HTTP personnalisé ou d'autres mesures de sécurité approuvées par votre équipe de sécurité.

Pour vérifier les jetons d'ID dans les réponses d'authentification, nous vous recommandons vivement d'utiliser une bibliothèque cliente d'API Google pour votre plate-forme ou une bibliothèque JWT à usage général.

Questions fréquentes (FAQ)

  • Le bouton One Tap et Se connecter avec Google est-il disponible dans les WebViews ?

    Non. Pour des raisons de sécurité, les utilisateurs ne doivent pas ajouter de sessions Google dans les WebViews. Par conséquent, les GIS sont désactivés dans les WebViews, car aucune session Google ne devrait y être présente.

  • Puis-je utiliser mon propre bouton Se connecter avec Google ? Non. Avec le flux côté serveur OAuth ou la version antérieure de la bibliothèque JavaScript Google Sign-In, les parties de confiance pouvaient utiliser les consignes relatives au branding de la connexion pour créer leurs propres versions des boutons Google Sign-In.

    Cependant, la fonctionnalité Se connecter avec Google a été supprimée. Tous les boutons Se connecter avec Google doivent être générés par la bibliothèque JavaScript Google Identity Services. Cette modification s'explique par deux raisons.

    • Certaines parties de confiance n'ont pas suivi les consignes, ce qui entraîne des boutons de connexion avec Google incohérents sur les sites Web.
    • En générant des éléments à partir de la bibliothèque, vous n'avez pas besoin de modifier quoi que ce soit lorsque les consignes relatives au branding de la connexion changent.

    Pour appliquer cette règle, la bibliothèque JavaScript n'expose qu'une API pour afficher un bouton, mais pas l'API permettant de démarrer le flux de connexion.

  • Que se passe-t-il si mon site Web n'active que One Tap, mais pas le bouton Se connecter avec Google ?

    Nous vous recommandons d'utiliser à la fois One Tap et le bouton "Se connecter avec Google" sur votre site Web. En raison du temps de latence exponentiel, il est possible que le mode Un Tap ne s'affiche pas à chaque fois. Lorsque les utilisateurs souhaitent vraiment se connecter à votre site Web avec leur compte Google, ils peuvent accéder à la boîte de dialogue de connexion principale et se connecter à l'aide du bouton "Se connecter avec Google". Une connexion réussie à l'aide du bouton "Se connecter avec Google" effacera l'état de la période de latence de la fonctionnalité One Tap afin qu'elle puisse s'afficher lors de la prochaine connexion. Les autres flux de boutons de Google ne peuvent pas effacer les états de temporisation du bouton One Tap, car ils se trouvent dans différents binaires JavaScript.

    Si votre site Web n'active que le bouton One Tap, mais pas le bouton Se connecter avec Google, les performances de votre flux One Tap peuvent baisser, car les états de temps de latence exponentiel ne sont pas effacés à temps.

  • Quand mon code API HTML est-il analysé ? Puis-je modifier mon code d'API HTML plus tard ?

    La bibliothèque JavaScript Google Identity Services analyse et exécute votre code d'API HTML lors de l'événement de chargement de la bibliothèque JavaScript ou de l'événement DomContentLoaded, selon la date la plus tardive.

    • Si l'événement DomContentLoaded est déclenché lorsque la bibliothèque JavaScript est chargée, votre code d'API HTML est analysé et exécuté immédiatement.
    • Sinon, la bibliothèque JavaScript ajoute un écouteur pour l'événement DomContentLoaded. Lorsqu'il est déclenché, l'écouteur analyse et exécute votre code d'API HTML.

    Notez également que l'analyse et l'exécution de votre code d'API HTML sont ponctuelles.

    • Après l'analyse et l'exécution, toute modification ultérieure apportée à votre code d'API HTML est ignorée.
    • Aucune API ne permet aux développeurs de déclencher le processus d'analyse ou d'exécution.