Applications Web

Publiez le script en tant qu'application Web si vous créez une interface utilisateur pour celui-ci. Par exemple, un script qui permet aux utilisateurs de planifier des rendez-vous avec des membres d'une équipe d'assistance est plus adapté à une application Web, afin que les utilisateurs puissent y accéder directement depuis leur navigateur.

Les scripts autonomes et les scripts liés aux applications Google Workspace peuvent être transformés en applications Web, à condition qu'ils répondent aux exigences suivantes.

Conditions requises pour les applications Web

Un script peut être publié en tant qu'application Web s'il répond aux exigences suivantes :

Paramètres de requête

Lorsqu'un utilisateur consulte une application ou qu'un programme envoie une requête HTTP GET à l'application, Google Apps Script exécute la fonction doGet. Lorsqu'un programme envoie une requête HTTP POST à l'application, Apps Script exécute doPost à la place. Dans les deux cas, l'argument e représente un paramètre d'événement qui peut contenir des informations sur les paramètres de requête. La structure de l'objet d'événement est présentée dans le tableau suivant :

Champs
e.queryString

Valeur de la partie de la chaîne de requête de l'URL, ou null si aucune chaîne de requête n'est spécifiée

name=alice&n=1&n=2
e.parameter

Objet de paires clé/valeur correspondant aux paramètres de requête. Seule la première valeur est renvoyée pour les paramètres qui en comportent plusieurs.

{"name": "alice", "n": "1"}
e.parameters

Objet semblable à e.parameter, mais avec un tableau de valeurs pour chaque clé

{"name": ["alice"], "n": ["1", "2"]}
e.pathInfo

Chemin d'URL après /exec ou /dev. Par exemple, si le chemin d'URL se termine par /exec/hello, les informations sur le chemin sont hello.
e.contextPath Non utilisé, toujours la chaîne vide.
e.contentLength

Longueur du corps de la requête pour les requêtes POST, ou -1 pour les requêtes GET

332
e.postData.length

Identique à e.contentLength

332
e.postData.type

Type MIME du corps POST

text/csv
e.postData.contents

Texte du contenu du corps POST

Alice,21
e.postData.name

Toujours la valeur "postData"

postData

Transmettez des paramètres tels que username et age à une URL comme suit :

https://script.google.com/.../exec?username=jsmith&age=21

Affichez les paramètres comme suit :

function doGet(e) {
  var params = JSON.stringify(e);
  return ContentService.createTextOutput(params).setMimeType(ContentService.MimeType.JSON);
}

Dans l'exemple précédent, doGet renvoie le résultat suivant :

{
  "queryString": "username=jsmith&age=21",
  "parameter": {
    "username": "jsmith",
    "age": "21"
  },
  "contextPath": "",
  "parameters": {
    "username": [
      "jsmith"
    ],
    "age": [
      "21"
    ]
  },
  "contentLength": -1
}

Les noms de paramètres suivants sont réservés par le système et ne doivent pas être utilisés dans les paramètres d'URL ni dans les corps POST :

  • c
  • sid

L'utilisation de ces paramètres peut entraîner une réponse HTTP 405 avec le message d'erreur "Sorry, the file you have requested does not exist" (Désolé, le fichier que vous avez demandé n'existe pas). Si possible, mettez à jour votre script pour utiliser d'autres noms de paramètres.

Déployer un script en tant qu'application Web

Pour déployer un script en tant qu'application Web, procédez comme suit :

  1. En haut à droite du projet de script, cliquez sur Déployer > Nouveau déploiement.
  2. À côté de "Sélectionner le type", cliquez sur Paramètres d'activation des types de déploiement > Application Web.
  3. Saisissez les informations sur votre application Web dans les champs sous "Configuration du déploiement".
  4. Cliquez sur Déployer.

Partagez l'URL de l'application Web avec les personnes qui doivent l'utiliser, à condition que vous leur ayez accordé l'accès.

Les applications Web déployées dans un domaine cessent de fonctionner si leur propriété est transférée vers un Drive partagé ou un compte dans un autre domaine. Pour résoudre ce problème, le nouveau propriétaire ou collaborateur doit redéployer l'application Web dans le nouveau domaine. Si l'application Web est déplacée vers son domaine d'origine, elle recommence à fonctionner pour ce domaine sans être redéployée.

Tester un déploiement d'application Web

Pour tester votre script en tant qu'application Web, procédez comme suit :

  1. En haut à droite du projet de script, cliquez sur Déployer > Tester les déploiements.
  2. À côté de "Sélectionner le type", cliquez sur Paramètres d'activation des types de déploiement > Application Web.
  3. Sous l'URL de l'application Web, cliquez sur Copier.

  4. Collez l'URL dans votre navigateur et testez votre application Web.

    Cette URL se termine par /dev et n'est accessible qu'aux utilisateurs disposant d'un accès en écriture au script. Cette instance de l'application exécute toujours le code enregistré le plus récemment et n'est destinée qu'aux tests pendant le développement.

Pour tester la fonctionnalité OAuth précise sur l' application Web, assurez-vous que votre projet ne dispose pas déjà d'autorisations. Pour invalider les autorisations existantes, utilisez ScriptApp.invalidateAuth. Pour toutes les applications Web déjà déployées et exécutées sous l'identité de l'utilisateur actif, modifiez le champ executeAs JSON dans le fichier manifeste en USER_DEPLOYING.

Lorsque vous déployez des applications Web pour qu'elles s'exécutent en tant que développeur, faites très attention lorsque vous gérez les jetons OAuth obtenus via ScriptApp.getOAuthToken. Ces jetons peuvent accorder à d'autres applications l'accès à vos données. Ne les transmettez jamais au client.

Autorisations

Les autorisations d'une application Web varient en fonction de la manière dont vous choisissez d'exécuter l'application :

  • Exécuter l'application en tant que moi : dans ce cas, le script s'exécute toujours en tant que vous, le propriétaire du script, quel que soit l'utilisateur qui accède à l'application Web.
  • Exécuter l'application en tant qu'utilisateur accédant à l'application Web : dans ce cas, le script s'exécute sous l'identité de l'utilisateur actif qui utilise l'application Web. Cette approche d'autorisation permet à l'application Web d'afficher l'adresse e-mail du propriétaire du script lorsque l'utilisateur autorise l'accès.

Pour éviter les abus, Apps Script impose des limites au rythme auquel les nouveaux utilisateurs peuvent autoriser une application Web qui s'exécute en tant qu'utilisateur. Ces limites dépendent, entre autres, du fait que le compte de publication appartienne ou non à un domaine Google Workspace.

Collaborez sur des applications Web à l'aide d'un Drive partagé. Lorsqu'une application Web est déployée dans un Drive partagé, le fait de choisir de l'exécuter "en tant que vous" entraîne son exécution sous l'autorité de l'utilisateur qui l'a déployée (car il n'y a pas de propriétaire de script).

Intégrer votre application Web dans Google Sites {:#embed-web-app}

Les applications Web intégrées sont toujours soumises à des autorisations d'accès pour éviter toute utilisation malveillante. Si votre application Web intégrée ne semble pas fonctionner, vérifiez si les autorisations définies par le propriétaire de l'application Web et l'administrateur du domaine autorisent son utilisation.

Pour intégrer une application Web dans Sites, vous devez d'abord la déployer. Vous avez également besoin de l'URL déployée de la boîte de dialogue Déployer.

Pour intégrer une application Web dans une page Sites, procédez comme suit :

  1. Ouvrez la page Sites sur laquelle vous souhaitez ajouter l'application Web.
  2. Sélectionnez Insérer > URL d'intégration.
  3. Collez l'URL de l'application Web, puis cliquez sur AJOUTER.

L'application Web s'affiche dans un cadre dans l'aperçu de la page. Lorsque vous publiez la page, les visiteurs de votre site devront peut-être autoriser l'application Web avant qu'elle ne s'exécute normalement. Les applications Web non autorisées présentent des invites d'autorisation à l'utilisateur.

Applications Web et historique du navigateur

Pour simuler une application multipage ou une application avec une interface utilisateur dynamique contrôlée à l'aide de paramètres d'URL, définissez un objet d'état pour représenter l'interface utilisateur ou la page de l'application, puis transmettez l'état à l'historique du navigateur lorsque l'utilisateur navigue dans votre application. Écoutez les événements d'historique afin que votre application Web affiche l'interface utilisateur appropriée lorsque l'utilisateur navigue en arrière et en avant à l'aide des boutons du navigateur. En interrogeant les paramètres d'URL au moment du chargement, demandez à votre application de créer dynamiquement son interface utilisateur en fonction de ces paramètres, ce qui permet à l'utilisateur de démarrer l'application dans un état particulier.

Apps Script fournit deux API JavaScript côté client asynchrones pour vous aider à créer des applications Web liées à l'historique du navigateur :

  • google.script.history fournit des méthodes permettant une réponse dynamique aux modifications de l'historique du navigateur. Cela inclut : la transmission d'états (objets simples que vous définissez) à l'historique du navigateur, le remplacement de l'état supérieur dans la pile d'historique et la définition d'une fonction de rappel d'écouteur pour répondre aux modifications de l'historique.

  • google.script.url permet de récupérer les paramètres d'URL et le fragment d'URL de la page actuelle, s'ils sont présents.

Ces API d'historique ne sont disponibles que pour les applications Web. Elles ne sont pas compatibles avec les barres latérales, les boîtes de dialogue ni les modules complémentaires. Cette fonctionnalité n'est pas non plus recommandée pour une utilisation dans des applications Web intégrées à un site.