Accès Web à Google Sheets

L'accès à Google Sheets suit l'identifiant que vous apportez. Sur le site web déployé, il y a deux façons d'entrer, côte à côte : se connecter avec Google (OAuth), ou choisir un fichier de clé de compte de service que votre propre navigateur utilise directement. Le chemin Unity / local conserve sa clé de compte de service locale à la machine, inchangée.

Sur le site déployé — OAuth, lecture et écriture

Sur le site déployé, un utilisateur connecté peut à la fois lire et écrire des feuilles Google via son propre jeton OAuth.

• Moindre privilège. Se connecter demande votre profil de base et un accès aux feuilles de calcul fichier par fichier (drive.file) : l’application ne peut lire et écrire que les fichiers de feuille de calcul que vous lui avez explicitement ouverts. Rien à l’échelle du compte — elle ne peut ni lister ni parcourir le reste de votre Drive, et un fichier que vous ne lui avez pas ouvert reste invisible.
• Le même plan du cœur. Une écriture sur le web passe par exactement le même plan du cœur et la même vérification à verrouillage optimiste partagée que tous les autres chemins — la feuille en direct est revérifiée juste avant l'envoi, si bien qu'une cellule qu'un tiers a modifiée depuis votre import est ignorée, jamais écrasée. Seule la couche de transport diffère : sur ce chemin, elle porte le jeton porteur OAuth.
• La LCA de la feuille fait autorité en dernier ressort. SheetForge ne décide pas qui peut écrire ; Google le fait. Un 403 de Google est retraduit en un message de permission honnête plutôt qu'une écriture partielle, si bien qu'un refus se lit comme un refus.

Le jeton OAuth est conservé dans le cookie de session (un JWT) et utilisé par des actions serveur. La seule exception est le sélecteur de fichiers de Google, décrit ci-dessous : c’est un widget Google qui s’exécute dans la page, donc l’ouvrir remet à la page un jeton d’accès de courte durée pour votre propre session.

Démarrer depuis le sélecteur — vous n'avez jamais besoin d'un ID

L'onglet connecté commence par Choisir une feuille de calcul depuis Google : le propre sélecteur de fichiers de Google s'ouvre par-dessus la page, vous choisissez la feuille de calcul, son ID atterrit dans le panneau et l'import se lance de lui-même. Choisir est aussi ce qui accorde à l'application l'accès à ce fichier sous drive.file, si bien qu'un seul geste fait les deux. Une ligne Feuille de calcul actuelle montre vers quoi le panneau est pointé.

Taper un ID à la main fonctionne toujours — cela s'est déplacé sous un pli Avancé : démarrer à partir d'un id de feuille de calcul, et un ID déjà enregistré continue de fonctionner exactement comme avant. La réserve honnête est énoncée là même : Google n'ouvre que les fichiers que vous avez déjà choisis au moins une fois, si bien qu'un ID pour un fichier jamais choisi est refusé jusqu'à ce que vous le choisissiez (la ligne Autoriser l'accès au fichier… ci-dessous couvre ce cas).

Ouvrir un fichier pour l’application — une seule fois

Sous drive.file, la permission grandit fichier par fichier. Si l'application rencontre une feuille de calcul à laquelle elle n'a pas encore accès — un ID tapé sous Avancé, un ID enregistré après un changement de compte —, elle ouvre le sélecteur de fichiers propre à Google avec cette feuille de calcul déjà repérée, dès l'instant où elle rencontre l'erreur de permission. Choisissez le fichier une fois, et l’import ou le push que vous aviez lancé se termine tout seul. À partir de là, cette feuille de calcul se comporte exactement comme avant.

• Rien à préparer à l’avance. Vous n’accordez pas l’accès par anticipation ; le sélecteur apparaît exactement quand c’est nécessaire, préréglé sur le fichier en question, et l’action que vous aviez demandée est automatiquement retentée une fois votre choix fait.
• Redonner l’accès reste toujours à portée de main. Le panneau Google garde une ligne Autoriser l’accès au fichier… qui rouvre le même sélecteur à tout moment — par exemple après être passé à un autre compte Google.
• Une limite honnête. Le sélecteur est un widget Google qui s’exécute dans la page, donc pendant qu’il est utilisé, la page détient un jeton d’accès de courte durée (valable une heure au maximum) pour votre session, obtenu auprès d’un point de terminaison de même origine qui exige votre connexion. C’est le même type de confiance que le chemin du fichier de clé ci-dessous accorde à la page — ce qui la protège, c’est la Content Security Policy stricte de l’application. Le jeton n’est ni stocké ni journalisé.

L'onglet du fichier de clé garde son champ d'ID à dessein : un compte de service n'a pas de session de navigation connectée avec laquelle choisir, si bien qu'un ID — avec la feuille partagée au compte — reste le moyen honnête d'y entrer.

Sur le site déployé — un fichier de clé de compte de service, signé par votre navigateur

Le deuxième onglet du panneau Google accepte un fichier de clé JSON de compte de service. Tout ce que fait cette clé se passe dans votre navigateur :

• La clé n'atteint jamais le serveur. Le navigateur lui-même signe la demande de jeton et appelle directement les API de Google, si bien que la clé, la demande signée, le jeton d'accès et les données de votre feuille ne touchent jamais les serveurs de SheetForge. Les routes de compte de service côté serveur restent verrouillées fermées (501) sur le site déployé, exactement comme avant — ce chemin ajoute une capacité sans en ouvrir une.
• Se souvenir de la clé est honnête sur ce qu'il stocke. Si vous choisissez de faire mémoriser la clé, le texte du fichier est aussitôt supprimé ; ce qui est conservé — sur cet appareil, dans le stockage du navigateur — est une clé de signature que les scripts de la page peuvent utiliser mais ne peuvent jamais relire. Quiconque peut ouvrir ce profil de navigateur pourrait tout de même la récupérer, donc traitez l'appareil comme vous traiteriez le fichier de clé lui-même. Oublier la clé la supprime aussitôt, dans tous les onglets ouverts, et l'application demande aussi à Google de révoquer le jeton d'accès actuel.
• Même plan, même vérification. Les lectures et écritures passent par le même plan du cœur et la même vérification pré-envoi que les autres chemins.

Le chemin Unity / local

La clé de compte de service utilisée par Unity et le serveur de développement local est lue depuis un chemin local à la machine et n'est jamais téléversée ni empaquetée — la même clé que décrit Configuration des feuilles Google ; gardez-la en dehors de Assets/ et en dehors du dépôt. Le dépôt ne contient aucun identifiant.

Les listes déroulantes se rafraîchissent à chaque push

Après un push depuis l'application web, les listes déroulantes de validation des données de la feuille sont réécrites automatiquement — tous les onglets en un seul lot, avec la liste déroulante d'une colonne de référence écrite comme une plage sur la colonne clé de la feuille cible, si bien qu'elle grandit à mesure que des enregistrements sont ajoutés. Une règle visant un onglet de feuille qui n'existe pas est ignorée et signalée. Cela correspond à ce qu'écrit le push Google de l'éditeur.

Quel chemin fait quoi

Le comportement d'écriture est identique quel que soit l'endroit où il s'exécute, car tous les chemins partagent le plan du cœur et la vérification pré-envoi. Seul le transport — un jeton de compte de service signé par le navigateur, un porteur OAuth par utilisateur, ou la clé du serveur local — change.

Pages associées

• Configuration des feuilles Google — créer le compte de service et la clé JSON pour le chemin Unity
• Sources, export et push — la chaîne de sécurité du Push que partage le chemin d'écriture web
• SheetForge Web — l'application navigateur dans laquelle vit cet accès