Контекст: я только что научился получать (загружать) данные из FireStore Dashboard. Очевидно, что намного проще просто открыть панель инструментов Google в браузере и увидеть своими глазами собственную панель инструментов Google. Тем не менее, в моей компании по личным причинам операторы не могут смотреть на третью Личную панель. Они могут видеть только внутренние панели мониторинга. Я пытаюсь найти обходной путь, где я могу получить / загрузить те же данные, которые использовались для заполнения панели мониторинга, и импортировать их в наше внутреннее решение на основе Dynatrace / ELK.
В учебных целях, чтобы загрузить данные панели управления Google, я выполнил:
1 - получить ACCESS_TOKEN с помощью gcloud
C:\Program Files (x86)\Google\Cloud SDK>gcloud auth application-default print-access-token
C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin\..\lib\third_party\google\auth\_default.py:69: UserWarning: Your application has authenticated using end user credentials from Google Cloud SDK. We recommend that most server applications use service accounts instead. If your application continues to use end user credentials from Cloud SDK, you might receive a "quota exceeded" or "API not enabled" error. For more information about service accounts, see https://cloud.google.com/docs/authentication/
warnings.warn(_CLOUD_SDK_CREDENTIALS_WARNING)
ya29. ... ACCESS-TOKEN ...7hu
2 - используя приведенный выше ACCESS_TOKEN, чтобы получить Данные приборной панели, например:
curl --location --request GET 'https://monitoring.googleapis.com/v3/projects/firetestjimis/timeSeries?filter=metric.type%20%3D%20%22firestore.googleapis.com%2Fdocument%2Fread_count%22&interval.endTime=2020-05-07T15:01:23.045123456Z&interval.startTime=2020-05-05T15:01:23.045123456Z' --header 'Authorization: Bearer ya29...ACCESS-TOKEN 7hu'
Очевидно, это всего лишь пример того, как узнать, сколько соединений удовлетворяет критериям фильтра. Я могу продолжать поиск, настраивая API и фильтры в соответствии с Google Cloud Metrics и Google Cloud API v3
Другой пример получения метады Dashboard на этот раз из API версии 1:
curl --location --request GET 'https://monitoring.googleapis.com/v1/projects/firetestjimis/dashboards' --header 'Authorization: Bearer ya29... ACCESS-TOKEN ...7hu'
Предупреждение при получении ACCESS-TOKEN от gcloud побуждает увидеть Руководство по аутентификации , и я это сделал. Что ж, здесь не объясняется, как исправить это предупреждение, и не объясняется, почему «Если ваше приложение продолжает использовать учетные данные конечного пользователя из Cloud SDK, вы можете получить ошибку« превышена квота »или« API не включен ». Я вижу, что мой трюк для получения данных из Dashboard работает, но, похоже, я полагаюсь на странный способ получить ACCESS-TOKEN.
Итак, мой прямой вопрос: каковы соответствующие шаги, чтобы вручную получить ACCESS -TOKEN и использовать его в curl / postman, избегая такого предупреждения?
Мне кажется, что на основе этого ответа на переполнение стека причина root: «... Это сообщение об ошибке означает вы используете учетную запись пользователя, а не учетную запись службы ... "Итак, как я могу это исправить? Нужно ли мне создавать учетную запись службы? Если да, то как? В конце принятого ответа я прочитал «... чтобы использовать истинное приложение по умолчанию, вы можете использовать gcloud auth application-default login ...» И именно так я регистрируюсь с gcloud: запустите gcloud auth application-default login , когда я открываю Google SingleSignOn, я выбираю свой адрес электронной почты того же пользователя, которого я зарегистрировал в учетной записи Firebase. В ответе также упоминается «... метод для привязки определенной учетной записи службы c - это gcloud auth activate-service-account --key-file ....» Я хочу попробовать, но какой ключевой файл это он / она о чем говорит?
Если это актуально, в моем случае я использую FireStore только в проекте Firebase (я не использую ничего, кроме FireStore).
*** ИЗМЕНИТЬ после ответа Джона
Мы скоро переводим этот проект в производство.
1 - Наше мобильное приложение создаст денежный перевод, разместив его в нашем внутреннем микросервисе . Такой почтовый запрос вернет CustomToken, сгенерированный на нашем внутреннем сервере NodeJs.
2 - Наш внутренний микросервис будет копировать такую передачу в Firestore и соответственно обновлять свое состояние в Firestore.
3 - Вместо нашего опроса приложения Mobil ie или прослушивания нашего внутреннего микросервиса, чтобы получить статус, он будет слушать Firestore для получения статуса из соответствующего документа. Чтобы слушать, он будет использовать CustomToken, возвращенный из сообщения на шаге 1. Наша компания хочет просто воспользоваться функцией базы данных в реальном времени от Google Firestore для этого проекта (реактивный подход).
Видите ли вы какое-либо соображение при сравнении того, что я делаю, с вашим утверждением: «Google в большинстве случаев предпочитает, чтобы вы разрешали использование учетной записи службы»?
CustomToken создается внутри с этим NodeJs сервер и в зависимости от uid, полученного от аутентифицированного пользователя аутентификация / пользователи из Google Firebase :
const admin = require('firebase-admin');
exports.serviceAccount = {
"type": "service_account",
"project_id": "firetestjimis",
"private_key_id": "ecfc6 ... fd05923",
"private_key": "-----BEGIN PRIVATE KEY-----\nMIIE .... 5EKvQ==\n-----END PRIVATE KEY-----\n",
"client_email": "firebase-adminsdk-fg6p9@firetestjimis.iam.gserviceaccount.com",
"client_id": "102422819688924138150",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/firebase-adminsdk-fg6p9%40firetestjimis.iam.gserviceaccount.com"
}
admin.initializeApp({
credential: admin.credential.cert(exports.serviceAccount)
});
var uid = "NS .... Ro2"; //copied from https://console.firebase.google.com/project/firetestjimis/authentication/users
var claim = {
control: true
};
admin.auth().createCustomToken(uid)
.then(function (customToken) {
console.log(customToken)
})
.catch(function (error) {
console.log("Error creating custom token:", error);
});
Наш мобильный (пример в Angular, но та же идея для IOS и Android) содержит файл SERVICE_ACCOUNT_JSON_FILE, который я скачал следующим образом:
environment.ts:
export const environment = {
production: false,
firebaseConfig: {
apiKey: "AIzaSy ... 3DCGihK3xs",
authDomain: "firetestjimis.firebaseapp.com",
databaseURL: "https://firetestjimis.firebaseio.com",
projectId: "firetestjimis",
storageBucket: "firetestjimis.appspot.com",
messagingSenderId: "795318872350",
appId: "1:7953 ... 32b26fb53dc810f"
}
};
app.component.ts
public transfers: Observable<any[]>;
transferCollectionRef: AngularFirestoreCollection<any>;
constructor(public auth: AngularFireAuth, public db: AngularFirestore) {
this.listenSingleTransferWithToken();
}
async listenSingleTransferWithToken() {
await this.auth.signInWithCustomToken("eyJh ### CUSTOMTOKEN GENERATED FROM INTERNAL NODEJS SERVER ABOVE ### CVg");
this.transferCollectionRef = this.db.collection<any>('transfer', ref => ref.where("id", "==", "1"));
this.transfers = this.transferCollectionRef.snapshotChanges().map(actions => {
return actions.map(action => {
const data = action.payload.doc.data();
const id = action.payload.doc.id;
return { id, ...data };
});
});
}
}
Я понимаю, что создание CustomToken и его использование с нашего мобильного телефона полностью зависит от учетной записи службы. Я прав? Я пропустил какую-то концепцию, и я использую ПОЛЬЗОВАТЕЛЬСКИЙ КРЕДИТ за сценой, и что-то, что правильно работает в среде DEV, может вызвать сюрприз при производстве? Очевидно, что для этого вопроса все исходит из моей бесплатной учетной записи, но в производстве это будет платная учетная запись, но код и шаги здесь будут точно такими же.