Champs d'application des autorisations pour les modules complémentaires d'éditeur

Les utilisateurs doivent autoriser les modules complémentaires et autres applications qui accèdent à leurs données ou agissent en leur nom. Lorsqu'un utilisateur exécute un module complémentaire pour la première fois, l'interface utilisateur du module complémentaire affiche une invite d'autorisation pour démarrer le flux d'autorisation.

Au cours de ce processus, l'invite indique à l'utilisateur ce que l'application souhaite faire avec l'autorisation. Par exemple, un module complémentaire peut demander l'autorisation de lire le message électronique d'un utilisateur ou de créer des événements dans son agenda. Le projet de script du module complémentaire définit ces autorisations individuelles en tant que habilitations OAuth.

Vous déclarez les champs d'application dans votre fichier manifeste à l'aide de chaînes d'URL. Pendant le flux d'autorisation, Apps Script présente à l'utilisateur une description lisible du champ d'application. Par exemple, votre module complémentaire peut utiliser le champ d'application "Lire le document actuel", qui est écrit dans votre fichier manifeste sous la forme https://www.googleapis.com/auth/documents.currentonly. Lors du processus d'autorisation, un module complémentaire avec ce champ d'application demande à l'utilisateur d'autoriser le module complémentaire à afficher et gérer les documents dans lesquels cette application a été installée.

Remarque : Le champ d'application currentonly n'est disponible que dans les services Apps Script. Cela n'inclut pas les services avancés Apps Script ni les appels directs aux API Google Workspace.

Remarque : Les champs d'application utilisés par Apps Script pour ses différents services chevauchent ceux utilisés par l'API associée. Par exemple, le service Agenda d'Apps Script utilise de nombreux niveaux d'accès identiques à ceux de l'API Calendar. Vous pouvez rechercher les champs d'application requis par des méthodes de service Apps Script spécifiques dans la documentation de référence d'Apps Script.

Afficher les portées

Pour afficher les champs d'application actuellement requis par votre projet de script, procédez comme suit :

1. Ouvrez le projet de script.
2. Sur la gauche, cliquez sur Vue d'ensemble .
3. Affichez les habilitations sous "Project OAuth Scopes" (Habilitations OAuth du projet).

Vous pouvez également afficher les portées actuelles du projet de script dans le fichier manifeste du projet, sous le champ oauthScopes, mais uniquement si vous avez défini ces portées explicitement.

Définir des niveaux d'accès explicites

Apps Script détermine automatiquement les autorisations dont un script a besoin en analysant son code à la recherche d'appels de fonction qui les requièrent. Pour la plupart des scripts, cela suffit et vous fait gagner du temps, mais pour les modules complémentaires publiés, vous devez exercer un contrôle plus direct sur les niveaux d'accès.

Par exemple, Apps Script peut attribuer par défaut au projet de script d'un module complémentaire le champ d'application très permissif https://mail.google.com. Lorsqu'un utilisateur autorise un projet de script avec ce champ d'application, le projet obtient un accès complet au compte Gmail de l'utilisateur. Pour les modules complémentaires publiés, vous devez remplacer ce champ d'application par un ensemble plus limité qui couvre les besoins du module complémentaire et rien de plus.

Avertissement : Utilisez toujours l'ensemble de niveaux d'accès le moins permissif possible. Pour protéger les informations utilisateur, les modules complémentaires et autres applications publiées ne doivent jamais demander plus d'autorisations que nécessaire. Les niveaux d'accès requis par votre module complémentaire sont examinés lors du processus d'examen des modules complémentaires pour la publication. Si le module complémentaire utilise des niveaux d'accès trop larges, il ne peut pas être approuvé.

Vous pouvez définir explicitement les autorisations utilisées par votre projet de script en modifiant son fichier manifeste. Le champ de fichier manifeste oauthScopes est un tableau de tous les champs d'application utilisés par le module complémentaire. Pour définir les autorisations de votre projet, procédez comme suit :

1. Affichez les champs d'application actuellement utilisés par votre module complémentaire. Déterminez les modifications à apporter, par exemple en utilisant un champ d'application plus étroit.
2. Ouvrez le fichier manifeste de votre module complémentaire.
3. Recherchez le champ de premier niveau intitulé oauthScopes. Si elle n'est pas présente, vous pouvez l'ajouter.

4. Le champ oauthScopes spécifie un tableau de chaînes. Pour définir les niveaux d'accès utilisés par votre projet, remplacez le contenu de ce tableau par les niveaux d'accès que vous souhaitez utiliser. Par exemple, pour un module complémentaire Éditeur qui étend Sheets, vous pouvez avoir les éléments suivants :

   {
     ...
     "oauthScopes": [
       "https://www.googleapis.com/auth/script.container.ui",
       "https://www.googleapis.com/auth/spreadsheets"
     ],
     ...
   }
   

5. Enregistrez les modifications apportées au fichier manifeste.

Validation OAuth

L'utilisation de certains périmètres OAuth sensibles peut nécessiter que votre module complémentaire soit soumis à la validation du client OAuth avant de pouvoir être publié. Pour en savoir plus, consultez les guides suivants :

• Validation du client OAuth pour Apps Script
• Applications non validées
• Questions fréquentes sur la validation OAuth
• Règlement relatif aux données utilisateur dans les services d'API Google

Niveaux d'accès restreints

Certains niveaux d'accès sont restreints et soumis à des règles supplémentaires qui permettent de protéger les données utilisateur. Si vous prévoyez de publier un module complémentaire Gmail ou de l'éditeur qui utilise un ou plusieurs champs d'application restreints, il doit respecter toutes les restrictions spécifiées avant de pouvoir être publié.

Consultez la liste complète des champs d'application restreints avant de tenter de publier. Si votre module complémentaire en utilise, vous devez respecter les exigences supplémentaires pour les niveaux d'accès spécifiques aux API avant de le publier.

Remarque : Évitez d'utiliser des niveaux d'accès restreints dans votre module complémentaire si possible. Il est plus facile de passer l'examen des modules complémentaires pour une publication publique si vous ne les utilisez pas. Vous pouvez utiliser librement les étendues restreintes pour les modules complémentaires non publics.

L'extension Google Workspace Developer Tools pour Visual Studio Code fournit des informations de diagnostic pour tous les champs d'application, y compris leur description et leur sensibilité ou leur restriction.

Niveaux d'accès des modules complémentaires de l'éditeur

Lorsque vous créez un module complémentaire Editor, les champs d'application requis sont déterminés par le service et les méthodes Apps Script utilisés par le code du module complémentaire. Par exemple, un module complémentaire Sheets peut avoir besoin du champ d'application https://www.googleapis.com/auth/spreadsheets.readonly pour lire les informations de différentes feuilles de calcul Google Sheets.

Apps Script détermine automatiquement les champs d'application requis par les services que vous utilisez lorsque vous ajoutez du code à votre projet de script. Pour les modules complémentaires Editor, vous pouvez souvent vous contenter de cette collecte automatique de portée au lieu de déterminer vous-même les portées et de les définir explicitement.

Si vous ne définissez pas explicitement vos portées et que votre module complémentaire Editor ne lit ou n'écrit que dans le fichier de l'éditeur ouvert, ajoutez le commentaire suivant à l'un des fichiers de votre projet de script :

  /**
   * @OnlyCurrentDoc
   */

Ce commentaire indique à Apps Script de limiter les niveaux d'accès aux fichiers de l'éditeur à currentonly. Par exemple, si vous ajoutez ce commentaire à un fichier de projet de script de module complémentaire Google Sheets, vous spécifiez que le module complémentaire n'a besoin d'une autorisation que pour fonctionner sur la feuille actuellement ouverte, et non sur d'autres feuilles que l'utilisateur peut avoir dans Google Drive. À l'inverse, vous ne devez pas utiliser ce commentaire si votre module complémentaire Sheets doit lire ou écrire des données dans une feuille que l'utilisateur n'a pas encore ouverte.

Remarque : Le champ d'application currentonly n'est disponible que dans les services Apps Script. Cela n'inclut pas les services avancés Apps Script ni les appels directs aux API Google Workspace.