Firebase-tools: Erreur d'authentification ADC : des étendues sont requises pour cette demande

Créé le 29 mai 2018  ·  46Commentaires  ·  Source: firebase/firebase-tools

Bonjour, j'essaie d'automatiser le déploiement des fonctions Firebase. Lorsque j'exécute quelque chose comme "GOOGLE_APPLICATION_CREDENTIALS=utilisation de la base de feu--non-interactive --debug” J'ai l'erreur ci-dessous

Informations sur les versions

3.18.5

Informations sur la plate-forme

nœud de conteneur

Étapes à reproduire

/usr/bin/docker run --rm -v /workspace:/workspace -e GOOGLE_APPLICATION_CREDENTIALS=node:6.14-alpine node_modules/firebase-tools/bin/firebase use--déboguer

Comportement prévisible

Être authentifié

Comportement réel

[2018-05-29T15:57:32.507Z] > la commande nécessite des étendues : ["email", "openid", "https://www.googleapis.com/auth/cloudplatformprojects.readonly", "https://www .googleapis.com/auth/firebase”]
[2018-05-29T15:57:32.507Z] > tentative d'authentification via les informations d'identification par défaut de l'application
[2018-05-29T15:57:32.547Z] ! erreur d'auto-authentification : des étendues sont requises pour cette demande.
[2018-05-29T15:57:32.547Z] > aucune information d'identification n'a pu être trouvée ou récupérée automatiquement

Avez-vous des suggestions?

Commentaire le plus utile

@mbleigh une mise à jour ? confirmant qu'à partir de maintenant, la CLI firebase ne peut pas utiliser un compte de service pour se déployer ? nous le voulons pour l'outil CI. la prise en charge de GOOGLE_APPLICATION_CREDENTIALS ne fonctionne donc pas ?

Tous les 46 commentaires

Bonjour, les informations d'identification requises ne sont pas GOOGLE_APPLICATION_CREDENTIALS, donc cette ligne ne vous aide pas réellement.

Vous devrez générer un jeton CI, puis exécuter la commande avec l'indicateur --token, voir https://github.com/firebase/firebase-tools#using -with-ci-systems pour plus d'informations.

Salut,
et qu'en est-il de https://github.com/firebase/firebase-tools/pull/417 ?
Il semble que GOOGLE_APPLICATION_CREDENTIALS soit implémenté et firebase-tools utilise google-auto-auth pour l'obtenir.

Ou je me trompe?

Je n'utiliserais pas de jeton CI car je voudrais m'authentifier avec un compte de service et non un utilisateur Google (GSuite ou Cloud Identity ou autre)

Merci

Salut,
il semble que la bibliothèque appelle firebase-public.firebaseio. com:443 et a un code de retour HTTP de 200 mais une réponse de 0 octet

Salut, tu as raison. Désolé, j'ai oublié ce PR. Je ne suis pas très familier avec cela. Michael, peux-tu jeter un œil quand tu seras de retour au bureau ?

Salut @laurenzlong @mbleigh ,
J'ai trouvé que la configuration de "Domain Wide Authority" pour le compte de service permet de s'authentifier.
Mais maintenant j'ai le problème suivant :

GOOGLE_APPLICATION_CREDENTIALS=<path_to_json> firebase deploy --only functions --non-interactive --project=<project_id> --debug

[2018-06-04T09:25:46.202Z] ----------------------------------------------------------------------
[2018-06-04T09:25:46.211Z] CLI Version:   3.18.5
[2018-06-04T09:25:46.212Z] Platform:      linux
[2018-06-04T09:25:46.212Z] Node Version:  v6.14.2
[2018-06-04T09:25:46.212Z] Time:          Mon Jun 04 2018 09:25:46 GMT+0000 (UTC)
[2018-06-04T09:25:46.213Z] ----------------------------------------------------------------------

[2018-06-04T09:25:46.238Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[2018-06-04T09:25:46.238Z] > attempting to authenticate via app default credentials
[2018-06-04T09:25:46.445Z] xxxx.x.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xx
[2018-06-04T09:25:46.446Z] > retrieved access token via default credentials
[2018-06-04T09:25:46.449Z] >>> HTTP REQUEST GET https://admin.firebase.com/v1/projects/<project_id>  

 Mon Jun 04 2018 09:25:46 GMT+0000 (UTC)
[2018-06-04T09:25:47.067Z] <<< HTTP RESPONSE 404 server=nginx, date=Mon, 04 Jun 2018 09:25:47 GMT, content-type=application/json; charset=utf-8, content-length=87, connection=close, x-content-type-options=nosniff
[2018-06-04T09:25:47.069Z] <<< HTTP RESPONSE BODY code=PROJECT_NOT_FOUND, message=The specified project was not found.

Le compte de service a des autorisations d'éditeur sur le projet, et si j'utilise une identité Google (pas un compte svc), le problème n'existe pas

J'ai trouvé ce problème similaire (mais ils utilisent un jeton) https://github.com/firebase/firebase-tools/issues/744

Merci

Non, je me trompe.
Si j'exécute Firebase, j'ai à nouveau :

[2018-06-04T14:39:38.660Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase"]
[2018-06-04T14:39:38.660Z] > attempting to authenticate via app default credentials
[2018-06-04T14:39:38.693Z] ! auto-auth error: Scopes are required for this request.
[2018-06-04T14:39:38.694Z] > no credentials could be found or automatically retrieved

Même comportement même avec un compte de service auquel le rôle Owner attribué en essayant de faire quoi que ce soit à l'aide de l'outil CLI firebase :

$ export GOOGLE_APPLICATION_CREDENTIALS=account.json
$ firebase list --debug
[2018-06-05T12:15:17.340Z] ----------------------------------------------------------------------
[2018-06-05T12:15:17.343Z] Command:       /usr/local/bin/node /usr/local/bin/firebase list --debug
[2018-06-05T12:15:17.343Z] CLI Version:   3.18.5
[2018-06-05T12:15:17.343Z] Platform:      linux
[2018-06-05T12:15:17.343Z] Node Version:  v10.3.0
[2018-06-05T12:15:17.343Z] Time:          Tue Jun 05 2018 12:15:17 GMT+0000 (UTC)
[2018-06-05T12:15:17.343Z] ----------------------------------------------------------------------

[2018-06-05T12:15:17.347Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase"]
[2018-06-05T12:15:17.348Z] > attempting to authenticate via app default credentials
[2018-06-05T12:15:17.352Z] ! auto-auth error: Scopes are required for this request.
[2018-06-05T12:15:17.352Z] > no credentials could be found or automatically retrieved

Error: Command requires authentication, please run firebase login

Un indice mineur est que le jeton d'accès est vide (j'ai le même problème, j'ai décodé le JWT)

C'est implicite de par sa forme
xxxx.x.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Le x du milieu est la charge utile des données et a une taille de 1 caractère, il n'est donc clairement pas très complet.

firebase-tools utilise google-auto-auth pour obtenir un jeton, donc je pense que le problème est peut-être là.

Oups, la nouvelle version ( 3.18.6 ) ne semble toujours pas passer authScopes à autoAuth() . Si j'ajoute une instruction de journal avant cette ligne : https://github.com/firebase/firebase-tools/blob/b2594467d8980c5a1e2b8c4aff3de9877a98b42b/lib/requireAuth.js#L21
Je reçois authScopes: undefined .

Si j'ajoute

authScopes = [
  scopes.EMAIL,
  scopes.OPENID,
  scopes.CLOUD_PROJECTS_READONLY,
  scopes.FIREBASE_PLATFORM,
];

avant cette ligne, il procède à l'acquisition d'un jeton d'accès, mais échoue avec PROJECT_NOT_FOUND

Aussi @tomlarkworthy , ce jeton OAuth n'est pas JWT, il ne devrait donc pas contenir la partie centrale. Si vous l'exécutez dans https://developers.google.com/apis-explorer/#search/oauth2/oauth2/v2/oauth2.tokeninfo , il est signalé comme un jeton valide avec "scope": "https://www.googleapis.com/auth/cloudplatformprojects.readonly https://www.googleapis.com/auth/plus.me https://www.googleapis.com/auth/firebase https://www.googleapis.com/auth/userinfo.email",

Merci! OK Donc, quand j'obtiens l'erreur de projet introuvable. Lorsque je décode le token, je n'ai qu'une seule portée " https://www.googleapis.com/auth/cloud-platform ".

Il y a une différence entre un jeton "normal" (c'est-à-dire un jeton acquis via firebase login ):

{
 "issued_to": "563584335869-fgrhgmd47bqnekij5i8b5pr03ho849e6.apps.googleusercontent.com",
 "audience": "563584335869-fgrhgmd47bqnekij5i8b5pr03ho849e6.apps.googleusercontent.com",
 "user_id": "xxxyyy",
 "scope": "https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloudplatformprojects.readonly https://www.googleapis.com/auth/firebase https://www.googleapis.com/auth/plus.me",
 "expires_in": 3484,
 "email": "[email protected]",
 "verified_email": true,
 "access_type": "offline"
}

et un généré à partir d'un compte de service (SA) :

{
 "issued_to": "1160xxxx",
 "audience": "1160xxxx",
 "user_id": "1160xxxx",
 "scope": "https://www.googleapis.com/auth/cloudplatformprojects.readonly https://www.googleapis.com/auth/plus.me https://www.googleapis.com/auth/firebase https://www.googleapis.com/auth/userinfo.email",
 "expires_in": 3563,
 "email": "[email protected]",
 "verified_email": true,
 "access_type": "offline"
}

Il semble donc que le jeton ne soit pas émis à droite audience et user_id , qui devrait être celui de https://github.com/firebase/firebase-tools/blob/376678fef91f71de5859f14d8374b2d8d2731980/ lib/api.js#L84

@tomlarkworthy toujours étrange, mon authScope est undefined moins que j'ajoute explicitement les bonnes portées. Aviez-vous firebase logout avant d'exécuter celui-ci ?

OK, cet ID client est le client oath2, qui a des domaines très spécifiques qu'il peut travailler configurés hors de notre portée. Et/ou nécessite une interaction de l'utilisateur sur localhost. C'est donc très difficile d'obtenir une autorisation dans CI.

Je lance le mien sur une fonction. Je n'ai pas eu la même erreur que toi. J'ai un projet non trouvé comme l'affiche originale.

Si je construis mon propre jeton à partir du compte de service et que je le transmets avec --token, j'obtiens :-

RÉPONSE HTTP 401varie=X-Origin, Origin,Accept-Encoding, www-authenticate=Bearer realm=" https://accounts.google.com/ ", content-type=application/json ; charset=UTF-8, date=Jeu, 07 juin 2018 00:16:43 GMT, expire=Jeu, 07 juin 2018 00:16:43 GMT, cache-control=private, max-age=0, x-content- type-options=nosniff, x-frame-options=SAMEORIGIN, x-xss-protection=1 ; mode=bloc, serveur=GSE, alt-svc=quic=":443" ; ma=2592000; v="43,42,41,39,35", accept-ranges=none, connection=close
[2018-06-07T00:16:43.786Z] <<< CORPS DE RÉPONSE HTTP error=unauthorized_client, error_description=Unauthorized
[2018-06-07T00:16:43.791Z] > la commande requiert des étendues : ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www .googleapis.com/auth/firebase"]
[2018-06-07T00:16:43.792Z] > autorisation via l'option --token
[2018-06-07T00:16:43.792Z] > jeton d'accès actualisé avec des étendues : ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https:/ /www.googleapis.com/auth/firebase"]
[2018-06-07T00:16:43.793Z] >>> POSTE DE DEMANDE HTTP https://www.googleapis.com/oauth2/v3/token
{ refresh_token : 'ya29.c.XXXXXXXXXXXX',
client_id : '563584335869-fgrhgmd47bqnekij5i8b5pr03ho849e6.apps.googleusercontent.com',
client_secret : 'j9iVZfS8kkCEFUPaAeJV0sAi',
grant_type : 'refresh_token',
champ d'application : 'email openid https://www.googleapis.com/auth/cloudplatformprojects.readonly https://www.googleapis.com/auth/firebase ' }

Je pense que cet identifiant de client sous serment gêne ?

@tomlarkworthy pas nécessairement difficile - je teste la configuration avec clientId maintenant.

J'ai essayé de créer un projet personnalisé avec son propre client oauth et de remplacer les firebase-tools client_id et secret_id. Ensuite, j'ai autorisé l'application Web serment, copié le jeton et l'ai utilisé pour appeler firebase-tools. Il emprunte un chemin légèrement différent et actualise avec succès le jeton, mais ne parvient pas ensuite à obtenir la liste des projets. J'ai confirmé dans le décodeur de jetons qu'il avait la portée en lecture seule de cloudplatformprojects, il aurait donc dû pouvoir les lire.

info : stderr : [2018-06-07T01:02:21.126Z] Remplacements d'environnement : FIREBASE_CLIENT_ID, FIREBASE_CLIENT_SECRET
[2018-06-07T01:02:21.126Z] -------------------------------------- --------------------------------

info : stderr : [2018-06-07T01:02:21.138Z] > la commande requiert des étendues : ["email","openid"," https://www.googleapis.com/auth/cloudplatformprojects.readonly "," https ://www.googleapis.com/auth/firebase "," https://www.googleapis.com/auth/cloud-platform "]

info : stderr : [2018-06-07T01:02:21.138Z] > autorisation via l'option --token
[2018-06-07T01:02:21.140Z] > jeton d'accès actualisé avec des étendues : ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https:/ /www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[2018-06-07T01:02:21.140Z] >>> POSTE DE DEMANDE HTTP https://www.googleapis.com/oauth2/v3/token
{ refresh_token : 'ya29.XXX',
client_id : '278696186940-fbqtl733l62g4qj8aekr4i66cpo0k5c1.apps.googleusercontent.com',
client_secret : 'XXXX',
grant_type : 'refresh_token',
champ d'application : 'email openid https://www.googleapis.com/auth/cloudplatformprojects.readonly https://www.googleapis.com/auth/firebase https://www.googleapis.com/auth/cloud-platform ' }
Mer. 06 juin 2018 18:02:21 GMT-0700 (PDT)

info : stderr : [2018-06-07T01:02:21.318Z] <<< RÉPONSE HTTP 200 x-google-netmon-label=/bns/ph/borg/ph/bns/apiserving/prod_hightraffic_api_frontend.server/998, x -google-gfe-backend-request-info=eid=HYQYW5jODYyytgbB3JfoAg, cache-control=no-cache, no-store, max-age=0, must-revalidate, pragma=no-cache, expires=Lun, 01 janvier 1990 00:00:00 GMT, date=Jeu, 07 juin 2018 01:02:21 GMT, varier=X-Origin, Origin,Accept-Encoding, x-google-session-info=GgIYBiAB, content-type=application/json ; charset=UTF-8, x-content-type-options=nosniff, x-frame-options=SAMEORIGIN, x-xss-protection=1 ; mode=block, server=GSE, x-google-servertype=apiserving, x-google-gfe-request-trace=acsfoh11:443,phnm21-v6:9897,/bns/ph/borg/ph/bns/apiserving/prod_hightraffic_api_frontend .server/998,phnm21-v6:9897,acsfoh11:443, x-google-gslb-service=apiserving-hightraffic, x-google-backends=plbn61:9882,/bns/ph/borg/ph/bns/apiserving/ prod_hightraffic_api_frontend.server/998,phnm21-v6:9897,/bns/ph/borg/ph/bns/traffic-prod/shared-layer2-gfe/495,acsfoh11:443, x-google-dos-service-trace= main :identity-o-auth-2-service-migration , main:shared-layer2-gfe , x-google-service=identity-o-auth-2-service-migration,restricted-shared-layer2-grpc-aggregate, x -google-gfe-response-code-details-trace=response_code_set_by_backend,response_code_set_by_backend, x-google-gfe-response-body-transformations=gunzipped, x-google-shellfish-status=CA0gBEBG, alt-svc=quic=":443 "; ma=2592000; v="43,42,41,39,35", x-google-gfe-service-trace=identity-o-auth-2-service-migration,restricted-shared-layer2-grpc-aggregate, accept-ranges= aucun, connexion=fermer

info: stderr: [2018-06-07T01:02:21.319Z] >>> DEMANDE HTTP OBTENIR https://admin.firebase.com/v1/projects/docsite-go

Mer. 06 juin 2018 18:02:21 GMT-0700 (PDT)

info: stderr: [2018-06-07T01:02:21.652Z] <<< HTTP RESPONSE 404 server=nginx, date=Thu, 07 Jun 2018 01:02:21 GMT, content-type=application/json; charset=utf-8, content-length=87, connection=close, x-content-type-options=nosniff

info: stderr: [2018-06-07T01:02:21.652Z] <<< HTTP RESPONSE BODY code=PROJECT_NOT_FOUND, message=Le projet spécifié n'a pas été trouvé.

@tomlarkworthy remplacer client_id et secret avec des valeurs personnalisées ne fonctionnera pas, car Firebase utilise actuellement un client prédéfini qui est séparé de tout projet client (du moins c'est ce que je comprends).

De plus, l'option --token ne prend en charge que le jeton d'actualisation, que vous n'obtenez pas si vous avez un compte de service (encore une fois, d'après ce que je comprends).

Nous devons trouver un moyen simple de générer le jeton d'accès SA avec cet ID client, si possible.

Il peut être possible d'emprunter une autre route et d'appeler les API Firebase avec un client JWT au lieu d'un jeton OAuth, comme décrit ici : https://developers.google.com/identity/protocols/OAuth2ServiceAccount#jwt -auth

google/google-auth-library-nodejs , qui est utilisé en interne par stephenplusplus/google-auto-auth , fournit une méthode plus pratique/sécurisée pour le faire.

Je ne pense pas que nous puissions progresser.

https://github.com/firebase/firebase-tools/issues/647#issuecomment -361926336 semble avoir signalé un succès auparavant, mais je ne sais pas si cela est confirmé. Il semble que l'API Firebase en question (https://admin.firebase.com/v1/projects) soit privée et n'accepte que les jetons générés pour cet ID client.

Cela devrait peut-être être déposé en tant que demande de fonctionnalité - avoir la possibilité d'utiliser un compte de service pour le déploiement permettrait d'utiliser un seul identifiant (et découplé de n'importe quel utilisateur) pour déployer à la fois les ressources Firebase et GCP.

L'option --token de la CLI est censée recevoir un jeton d'actualisation , pas un jeton d'accès. C'est celui qui est généré à partir de firebase login:ci .

Je n'ai pas testé de manière approfondie l'autorisation de compte de service, mais je soupçonne qu'il peut y avoir une vérification IAM nécessitant une large autorisation dans le backend admin.firebase.com . Nous pouvons approfondir nos recherches, mais je ne m'attendrais pas nécessairement à une résolution ultra-rapide ici.

L'option --token de la CLI est destinée à recevoir un jeton d'actualisation

Oui, compris comme mentionné ci-dessus.

Il serait étonnant d'utiliser une clé SA pour déployer à partir d'environnements CI. Le jeton d'actualisation est lié à un utilisateur particulier, et il n'est pas clair comment l'utiliser pour authentifier les commandes gcloud afin d'administrer d'autres services GCP. Actuellement, nous devons fournir les deux types d'informations d'identification (jeton d'actualisation de l'utilisateur administrateur pour Firebase CLI et clé SA pour gcloud ).

Je suis capable de FIREBASE_TOKEN='<token_here>' firebase deploy --only firestore,storage (je n'ai pas essayé d'autres cibles, il est possible qu'elles fonctionnent) en utilisant un jeton généré pour un compte de service.

Le jeton réel a été généré pour un compte de service par le moteur de secrets GCP du coffre-fort avec le champ d'application " https://www.googleapis.com/auth/cloud-platform ".

Je confirme qu'il est impossible d'utiliser une clé SA + GOOGLE_APPLICATION_CREDENTIALS, avec le dernier cli firebase, toutes les commandes se terminent avec :

root<strong i="6">@frontend</strong>:/usr/src/app$ firebase list

Error: HTTP Error: 404, The specified project was not found.

Having trouble? Try firebase list --help

@cpick c'est intéressant, savez-vous comment le coffre-fort génère des jetons oauth pour le compte de service ?

@paolomainardi firebase list ne fonctionnera pas avec une clé SA car elle dépend d'une implémentation de liste de projet héritée. Cependant, à peu près tout le reste devrait le faire (bien que vous deviez d'abord activer quelques API). Je recommanderais d'essayer une autre commande et de voir.

Nous travaillons à obtenir un support complet pour GOOGLE_APPLICATION_CREDENTIALS sans sauter à travers un tas de cerceaux parce que nous pensons que cela débloque d'excellents cas d'utilisation.

@paolomainardi Je pense que l' implémentation de vault est (c'est juste une supposition après une recherche rapide dans son code).

Je pense aussi gcloud alpha iam service-accounts sign-jwt (encore une fois, une supposition quelque peu éclairée).

Merci beaucoup @cpick , je vous tiendrai au courant.

J'ai jeté un bref coup d'œil à cela et, en tant que test, j'ai essayé de forcer les informations d'identification d'un compte de service et un access_token dans requireAuth.js
dans une tentative pour au moins voir quelque chose fonctionner.

Il semble que le cli essaie toujours de contacter https://admin.firebase.com/v1/projects/ quoi qu'il arrive (vous pouvez comprendre ce que je veux dire avec le drapeau --debug . Si je lis le commentaire précédent dans ce numéro, c'est peut-être le « point de terminaison api qui ne fonctionne pas » avec les comptes svc.

J'ai testé d'autres points de terminaison avec de simples appels GET et ils semblent être ok :

pour réf


  • Modification codée en dur que j'ai apportée à requireAuth.js juste pour tester qui renverra un jeton d'accès svc_accounts avec de larges étendues
function getServiceAccountClient() {
  const credFile = '/path/to/cert.json';
  const keys = require(credFile);
  let client = new JWT(
    keys.client_email,
    null,
    keys.private_key,
    ["email","openid","https://www.googleapis.com/auth/cloud-platform", "https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase"],
  );
  return client;
};

function _autoAuth(options, authScopes) {
  return new Promise(function(resolve, reject) {
    var client = getServiceAccountClient();
    client.getAccessToken().then(res => {
      console.log(res);
     api.setAccessToken(res.token);
     resolve();

    }).catch(function (error) {
      console.error('Unable to recall targetClient access_token ' + error);
    });    

    /*
        logger.debug("> attempting to authenticate via app default credentials");
 ......

  • Client générique
const {JWT} = require('google-auth-library');

function getServiceAccountClient() {
    const credFile = '/path/to/cert.json';
    const keys = require(credFile);

    let client = new JWT(
      keys.client_email,
      null,
      keys.private_key,
      ["email","openid","https://www.googleapis.com/auth/cloud-platform", "https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase"],
    );
    return client;
  };

  var client = getServiceAccountClient();
    let project_id = 'your_project';
    let url = 'https://admin.firebase.com/v1/projects/' + project_id
    //let url = "https://firestore.googleapis.com/v1beta1/projects/" + project_id + "/databases/(default)/indexes"
    //let url = "https://firebaserules.googleapis.com/v1/projects/" + project_id  + "/rulesets" 

    client.requestAsync({url}).then(resp => {
      console.log(resp.data);
    }).catch(function (error) {
      console.error('Unable to list buckets: ' + error);
    }); 

Je suis en mesure de déployer enfin l' aide d' un compte de service pour firestore , storage et hosting après avoir effectué une modification à requireAuth.js comme Showin dans ce point essentiel
ADC qui était déjà là..>

Ce qui suit est essentiellement un hack et incomplet car il ne fonctionne pas avec le déploiement de functions . La solution complète mentionnée par mbleigh ci-dessus pour le « support de première classe » vaut la peine d'attendre.


Quoi qu'il en soit, je l'ai vérifié comme suit:

Commencez avec un compte firebase qui est également en contexte avec gcloud

  1. Obtenir une clé privée de compte de service
$ gcloud iam service-accounts list
NAME                                EMAIL
App Engine default service account  [email protected]
firebase-adminsdk                   firebase-adminsdk-h2v8k@firebase-auth-sal.iam.gserviceaccount.com

gcloud iam service-accounts keys  create `pwd`/svc.json --iam-account=firebase-adminsdk-h2v8k@firebase-auth-sal.iam.gserviceaccount.com
  1. Ajoutez le compte de service en tant que OWNER sur ce projet

  2. Accédez à la console cloud et activez certaines API :

https://console.developers.google.com/apis/api/cloudresourcemanager.googleapis.com/overview?project=<your_project>

https://console.developers.google.com/apis/api/firebasehosting.googleapis.com/overview?project=<your_project>
  1. Supprimer les identifiants locaux

Pour les gcloud et firebase

$ firebase logout
✔  Logged out from [email protected]

$ mv ~/.config/gcloud ~/.config/gcloud_backup
  1. Définir ADC env-var et déployer
export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/svc.json

$ firebase deploy -P firebase-auth-sal --only firestore,hosting,storage 
{ token: 'ya29.c.EmJ8B....',  res: null }

=== Deploying to 'firebase-auth-sal'...

i  deploying storage, firestore, hosting
i  storage: checking storage.rules for compilation errors...
✔  storage: rules file storage.rules compiled successfully
i  firestore: checking firestore.rules for compilation errors...
i  firestore: reading indexes from firestore.indexes.json...
✔  firestore: rules file firestore.rules compiled successfully
i  storage: uploading rules storage.rules...
i  firestore: uploading rules firestore.rules...
✔  firestore: deployed indexes in firestore.indexes.json successfully
i  hosting[fir-auth-sal]: beginning deploy...
i  hosting[fir-auth-sal]: found 1 files in public
✔  hosting[fir-auth-sal]: file upload complete
✔  storage: released rules storage.rules to firebase.storage/firebase-auth-sal.appspot.com
✔  firestore: released rules firestore.rules to cloud.firestore
i  hosting[fir-auth-sal]: finalizing version...
✔  hosting[fir-auth-sal]: version finalized
i  hosting[fir-auth-sal]: releasing new version...
✔  hosting[fir-auth-sal]: release complete

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/firebase-auth-sal/overview
Hosting URL: https://fir-auth-sal.firebaseapp.com
  1. Vérifier le déploiement

deployment_hosting

  1. Tentative functions déploiement de

functions types de déploiement de mobilesdk.googleapis.com terminaison client_id pour les fonctions firebase ou nécessite en quelque sorte 3LO .... mais ce n'est que conjecture

$ firebase deploy -P firebase-auth-sal --only functions --debug

[2018-12-24T01:36:44.034Z] >>> HTTP REQUEST GET https://servicemanagement.googleapis.com/v1/services/cloudfunctions.googleapis.com/projectSettings/firebase-auth-sal?view=CONSUMER_VIEW  

[2018-12-24T01:36:44.034Z] >>> HTTP REQUEST GET https://servicemanagement.googleapis.com/v1/services/runtimeconfig.googleapis.com/projectSettings/firebase-auth-sal?view=CONSUMER_VIEW  

[2018-12-24T01:36:44.486Z] <<< HTTP RESPONSE 404 vary=X-Origin, Referer, Origin,Accept-Encoding, content-type=application/json; charset=UTF-8, date=Mon, 24 Dec 2018 01:36:44 GMT, server=ESF, cache-control=private, x-xss-protection=1; mode=block, x-frame-options=SAMEORIGIN, x-content-type-options=nosniff, alt-svc=quic=":443"; ma=2592000; v="44,43,39,35", accept-ranges=none, connection=close
[2018-12-24T01:36:44.486Z] <<< HTTP RESPONSE BODY code=404, message=Method not found., status=NOT_FOUND

Error: HTTP Error: 404, Method not found.
[2018-12-24T01:36:44.495Z] Error Context: {
  "body": {
    "error": {
      "code": 404,
      "message": "Method not found.",
      "status": "NOT_FOUND"

Référence de bogue interne : 122552119

Y a-t-il des mises à jour sur ce problème @tinaliang ? Je pense que la prise en charge du compte de service pour l'authentification devrait être une priorité élevée.

Pas de mise à jour pour le moment...

Ma conclusion des derniers jours est que je n'ai pas besoin de fonctions spécifiquement Firebase Cloud, donc je peux utiliser les fonctions GCP Cloud https://cloud.google.com/functions/ qui fonctionnent comme prévu (le déploiement se fait via gcloud CLI) Cependant, cela n'est pas la vraie solution de contournement ... mais cela pourrait être utile pour quelqu'un :)

Dupliqué par #1175

Y a-t-il encore des mises à jour ? J'ai essayé de déployer mon application Firebase via Cloud Build. hosting etc. semble fonctionner et se déployer correctement. functions ne se déploierait pas correctement et j'obtiens le 404 , comme décrit ci-dessus, avec une configuration appropriée dans IAM. (Le compte de service cloudbuild a des droits sur "Firebase Admin" et "API Keys Admin".) Ce ticket doit avoir une priorité élevée 🔥

Aucune mise à jour pour le moment, mais nous espérons y jeter un œil bientôt.

@mbleigh une mise à jour ? confirmant qu'à partir de maintenant, la CLI firebase ne peut pas utiliser un compte de service pour se déployer ? nous le voulons pour l'outil CI. la prise en charge de GOOGLE_APPLICATION_CREDENTIALS ne fonctionne donc pas ?

Comme mentionné précédemment, toutes les commandes CLI firebase ne fonctionneront pas avec GOOGLE_APPLICATION_CREDENTIALS , mais un bon nombre devrait le faire. Le définir sur le chemin des informations d'identification de votre compte de service devrait être tout ce que vous avez à faire (en fait, c'est ce que fait le script test-hosting.sh , entre autres).

En utilisant firebase login:ci vous devriez pouvoir utiliser un jeton dans votre système CI

La formalisation de l'utilisation et des capacités de GOOGLE_APPLICATION_CREDENTIALS est dans notre esprit, mais nous ne pouvons pas nous engager sur un calendrier à ce sujet. Merci pour votre patience.

Pourriez-vous clarifier - les métadonnées d'instance ADC fonctionneraient-elles dans ce cas, ou seulement GOOGLE_APPLICATION_CREDENTIALS ?

N'importe qui sur ce fil: si vous vous sentez aventureux, j'aimerais que vous essayiez la branche sur #1463 et voyez si elle vous permet de faire les choses que vous cherchez à faire avec l'authentification du compte de service. Je pense que nous avons peut-être résolu la majorité des problèmes, mais j'aimerais avoir des tests externes à ce sujet.

@mbleigh firebase apps:list web échouera par intermittence la moitié du temps dans Cloud Build. L'exécution avec debug ne nous donne aucune information sur la raison de l'échec. Des idées sur ce qui pourrait être le cas?

[2020-02-13T21:25:55.987Z] ----------------------------------------------------------------------
[2020-02-13T21:25:55.991Z] Command:       /usr/local/bin/node /workspace/node_modules/.bin/firebase apps:list web -j --project=projectName --debug
[2020-02-13T21:25:55.991Z] CLI Version:   7.12.1
[2020-02-13T21:25:55.991Z] Platform:      linux
[2020-02-13T21:25:55.991Z] Node Version:  v10.18.0
[2020-02-13T21:25:55.992Z] Time:          Thu Feb 13 2020 21:25:55 GMT+0000 (Coordinated Universal Time)
[2020-02-13T21:25:55.992Z] ----------------------------------------------------------------------

De plus, la commande @mbleigh firebase use projectName échouera également par intermittence car elle ne parvient pas à extraire les bonnes informations d'identification du serveur de métadonnées :

[2020-02-13T21:49:41.050Z] ----------------------------------------------------------------------
[2020-02-13T21:49:41.055Z] Command:       /usr/bin/node /directory/node_modules/.bin/firebase --debug use projectName
[2020-02-13T21:49:41.056Z] CLI Version:   7.12.1
[2020-02-13T21:49:41.056Z] Platform:      linux
[2020-02-13T21:49:41.056Z] Node Version:  v10.16.3
[2020-02-13T21:49:41.056Z] Time:          Thu Feb 13 2020 21:49:41 GMT+0000 (Coordinated Universal Time)
[2020-02-13T21:49:41.056Z] ----------------------------------------------------------------------
[2020-02-13T21:49:41.057Z] 
[2020-02-13T21:49:41.073Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[2020-02-13T21:49:41.073Z] > attempting to authenticate via app default credentials
[2020-02-13T21:49:41.669Z] TypeError: Cannot create property 'refresh_token' on string 'Not Found
'
    at /directory/node_modules/google-auto-auth/node_modules/google-auth-library/lib/auth/oauth2client.js:208:28
    at /directory/node_modules/google-auto-auth/node_modules/google-auth-library/lib/auth/computeclient.js:85:7
    at Request._callback (/directory/node_modules/google-auto-auth/node_modules/google-auth-library/lib/transporters.js:106:7)
    at Request.self.callback (/directory/node_modules/request/request.js:185:22)
    at Request.emit (events.js:198:13)
    at Request.EventEmitter.emit (domain.js:448:20)
    at Request.<anonymous> (/directory/node_modules/request/request.js:1161:10)
    at Request.emit (events.js:198:13)
    at Request.EventEmitter.emit (domain.js:448:20)
    at IncomingMessage.<anonymous> (/directory/node_modules/request/request.js:1083:12)
    at Object.onceWrapper (events.js:286:20)
    at IncomingMessage.emit (events.js:203:15)
    at IncomingMessage.EventEmitter.emit (domain.js:448:20)
    at endReadableNT (_stream_readable.js:1145:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)

À partir du 10/02/20, j'ai commencé à voir des échecs intermittents lors de l'utilisation de cloudbuild pour le déploiement sur l'hébergement Firebase lors de l'utilisation d'un compte de service. Cela avait toujours été bien pendant un certain temps auparavant et maintenant, il semble que cela échoue le plus souvent. Je commence à me demander s'il existe un nouvel ensemble d'autorisations que je dois déléguer au compte de service afin qu'il puisse le faire avec succès. C'est devenu un peu un problème car la plupart de mes déploiements échouent tout simplement 😞

Vous trouverez ci-dessous une capture d'écran avec un exemple des versions et lorsqu'elles ont soudainement commencé à échouer :

image

L'erreur de débogage est très similaire au commentaire ci-dessus :

[2020-02-16T07:30:46.905Z] ----------------------------------------------------------------------
[2020-02-16T07:30:46.908Z] Command:       /usr/local/bin/node /home/node/.npm-global/bin/firebase deploy --only hosting -P project-production --debug
[2020-02-16T07:30:46.908Z] CLI Version:   7.8.1
[2020-02-16T07:30:46.908Z] Platform:      linux
[2020-02-16T07:30:46.909Z] Node Version:  v12.13.1
[2020-02-16T07:30:46.909Z] Time:          Sun Feb 16 2020 07:30:46 GMT+0000 (Coordinated Universal Time)
[2020-02-16T07:30:46.910Z] ----------------------------------------------------------------------
[2020-02-16T07:30:46.910Z] 
[2020-02-16T07:30:46.920Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[2020-02-16T07:30:46.920Z] > attempting to authenticate via app default credentials
[2020-02-16T07:30:47.023Z] TypeError: Cannot create property 'refresh_token' on string 'Not Found
'
    at /home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auto-auth/node_modules/google-auth-library/lib/auth/oauth2client.js:208:28
    at /home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auto-auth/node_modules/google-auth-library/lib/auth/computeclient.js:85:7
    at Request._callback (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auto-auth/node_modules/google-auth-library/lib/transporters.js:106:7)
    at Request.self.callback (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/request/request.js:185:22)
    at Request.emit (events.js:210:5)
    at Request.EventEmitter.emit (domain.js:475:20)
    at Request.<anonymous> (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/request/request.js:1161:10)
    at Request.emit (events.js:210:5)
    at Request.EventEmitter.emit (domain.js:475:20)
    at IncomingMessage.<anonymous> (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/request/request.js:1083:12)
    at Object.onceWrapper (events.js:299:28)
    at IncomingMessage.emit (events.js:215:7)
    at IncomingMessage.EventEmitter.emit (domain.js:475:20)
    at endReadableNT (_stream_readable.js:1184:12)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)

Error: An unexpected error has occurred.

Cela semble être lié à https://github.com/firebase/firebase-tools/issues/1970 (à savoir, l'obsolescence des anciens points de terminaison de métadonnées d'instance v1beta1 , qui sont toujours utilisés par l'ancien gcloud Auth bibliothèque utilisée par Firebase CLI..)

Cette page vous a été utile?
0 / 5 - 0 notes