L'autorisation de Google Drive à l'aide de JavaScript

Il est possible d'utiliser l'Api Google Javascript bibliothèque de client avec le Lecteur, mais vous devez être conscient qu'il ya des points de douleur.

Il y a 2 principaux sujets de l'heure, qui ont tous deux workarrounds:

Autorisation

D'abord si vous avez un oeil de près la façon dont Google Drive auth œuvres, vous vous rendrez compte que, après qu'un utilisateur a installé votre application Lecteur et tente d'ouvrir un fichier ou créer un nouveau fichier avec votre application, Lecteur initie l'autorisation OAuth 2.0 flux automatiquement et l'auth les paramètres sont définis à response_type=code et access_type=hors ligne.
Cela signifie essentiellement que pour l'instant, Lecteur apps sont obligés d'utiliser le protocole OAuth 2 côté serveur de flux qui ne va pas être d'une quelconque utilité pour le client de Javascript bibliothèque (qui n'utilise que le côté client de flux).

Le problème est que: Lecteur lance un côté serveur OAuth 2.0 couler, alors le Javascript de la bibliothèque du client initie une côté client OAuth 2.0 flux.

Cela peut fonctionner, tout ce que vous avez à faire est d'utiliser le code côté serveur pour traiter le code d'autorisation est revenu après que le Disque côté serveur de flux (vous devez l'échanger pour un jeton d'accès et un jeton d'actualisation).
De cette façon, seul le premier flux de l'utilisateur sera invité pour l'autorisation. Après la première fois que vous échangez le code d'autorisation, l'authentification de la page sera contourné automatiquement.

Côté serveur échantillons pour ce faire est disponible dans notre documentation.

Si vous n'avez pas le processus de l'échange/le auth code sur le serveur-côté débit, l'utilisateur sera invité pour l'authentification à chaque fois qu'il essaie d'utiliser votre application de Lecteur.

De la manipulation de contenu de fichier

Le deuxième problème est que le téléchargement et l'accès au Lecteur réel contenu du fichier n'est pas facile de nos client Javascript library. Vous pouvez toujours le faire, mais vous devrez utiliser le code Javascript personnalisé.

La lecture du contenu du fichier

Lorsqu'un fichier de métadonnées/un fichier objet est récupéré, il contient un downloadUrl attribut qui pointe vers le fichier de contenu. Il est maintenant possible de télécharger le fichier à l'aide de la SCRO demande et de la façon la plus simple d'auth est d'utiliser le protocole OAuth 2 jeton d'accès à une URL param. Donc juste ajouter &access_token=... à la downloadUrl et aller chercher le fichier à l'aide XHR ou par redirection de l'utilisateur vers l'URL.

Téléchargement du fichier contenu

Mise à JOUR mise à JOUR: Le téléchargement des points de terminaison ne désormais en charge de la SCRO.

~~Mise à JOUR: Le téléchargement des points de terminaison, à la différence du reste de la Voiture de l'API ne prennent pas en charge de la SCRO de sorte que vous aurez à utiliser l'astuce ci-dessous pour l'instant:~~

Le téléchargement d'un fichier est délicat car il n'est pas intégré dans le client de Javascript lib et vous ne pouvez pas entièrement le faire avec HTTP, comme décrit dans cette réponse parce que nous n'autorisons pas les requêtes inter-domaine sur ces API points de terminaison. Donc, vous ne devez prendre avantage de l'iframe proxy utilisé par notre code Javascript de la bibliothèque du client et de l'utiliser pour envoyer un construit en plusieurs parties demande au Lecteur de SDK. Grâce à @Alain, nous avons un exemple de la façon de le faire ci-dessous:

/**
 * Insert new file.
 *
 * @param {File} fileData File object to read data from.
 * @param {Function} callback Callback function to call when the request is complete.
 */
function insertFileData(fileData, callback) {
  const boundary = '-------314159265358979323846';
  const delimiter = "\r\n--" + boundary + "\r\n";
  const close_delim = "\r\n--" + boundary + "--";

  var reader = new FileReader();
  reader.readAsBinaryString(fileData);
  reader.onload = function(e) {
    var contentType = fileData.type || 'application/octet-stream';
    var metadata = {
      'title': fileData.fileName,
      'mimeType': contentType
    };

    var base64Data = btoa(reader.result);
    var multipartRequestBody =
        delimiter +
        'Content-Type: application/json\r\n\r\n' +
        JSON.stringify(metadata) +
        delimiter +
        'Content-Type: ' + contentType + '\r\n' +
        'Content-Transfer-Encoding: base64\r\n' +
        '\r\n' +
        base64Data +
        close_delim;

    var request = gapi.client.request({
        'path': '/upload/drive/v2/files',
        'method': 'POST',
        'params': {'uploadType': 'multipart'},
        'headers': {
          'Content-Type': 'multipart/mixed; boundary="' + boundary + '"'
        },
        'body': multipartRequestBody});
    if (!callback) {
      callback = function(file) {
        console.log(file)
      };
    }
    request.execute(callback);
  }
}

---

Pour améliorer tout cela, dans le futur on pourrait:

• Permettent aux développeurs de choisir le protocole OAuth 2.0 flux qu'ils veulent utiliser (côté serveur ou côté client) ou pour permettre au développeur de gérer l'authentification OAuth complètement.
• Permettre de la SCRO sur le /upload/... points de terminaison
• Permettre de la SCRO sur le exportLinks natif gDocs
• Nous devrions faire, il est plus facile de télécharger des fichiers à l'aide de notre client Javascript library.

Pas de promesses à ce point bien 🙂