Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Migrieren Sie von älterem HTTP zu HTTP v1

Apps, die die ältere FCM-HTTP-API verwenden, sollten die Migration auf die HTTP v1-API gemäß den Anweisungen in diesem Handbuch in Betracht ziehen. Die HTTP v1-API bietet gegenüber der Legacy-API folgende Vorteile:

  • Bessere Sicherheit durch Zugriffstoken Die HTTP v1-API verwendet kurzlebige Zugriffstoken gemäß dem OAuth2-Sicherheitsmodell. Falls ein Zugriffstoken öffentlich wird, kann es nur etwa eine Stunde lang böswillig verwendet werden, bevor es abläuft. Aktualisierungstoken werden nicht so oft übertragen wie die in der Legacy-API verwendeten Sicherheitsschlüssel, sodass die Wahrscheinlichkeit, dass sie erfasst werden, sehr viel geringer ist.

  • Effizientere Anpassung plattformübergreifender Nachrichten Für den Nachrichtentext verfügt die HTTP v1-API über gemeinsame Schlüssel für alle Zielinstanzen sowie plattformspezifische Schlüssel, mit denen Sie die Nachricht plattformübergreifend anpassen können. Auf diese Weise können Sie "Überschreibungen" erstellen, die in einer einzigen Nachricht leicht unterschiedliche Nutzdaten an verschiedene Clientplattformen senden.

  • Erweiterbarer und zukunftssicherer für neue Clientplattformversionen Die HTTP v1-API unterstützt vollständig Messaging-Optionen, die auf iOS, Android und Web verfügbar sind. Da jede Plattform einen eigenen definierten Block in der JSON-Nutzlast hat, kann FCM die API nach Bedarf auf neue Versionen und neue Plattformen erweitern.

Aktualisieren Sie den Serverendpunkt

Die Endpunkt-URL für die HTTP v1-API unterscheidet sich in folgenden Punkten vom alten Endpont:

  • Es ist versioniert mit /v1 im Pfad.
  • Der Pfad enthält die Projekt-ID des Firebase-Projekts für Ihre App im Format /projects/myproject-ID/ . Diese ID ist auf der Registerkarte Allgemeine Projekteinstellungen der Firebase-Konsole verfügbar.
  • Es gibt explizit die die angeben send wie :send .

Um den Serverendpunkt für HTTP v1 zu aktualisieren, fügen Sie diese Elemente dem Endpunkt im Header Ihrer Sendeanforderungen hinzu.

Vor

POST https://fcm.googleapis.com/fcm/send

Nach

POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send

Aktualisieren Sie die Autorisierung von Sendeanfragen

Anstelle der in älteren Anforderungen verwendeten Serverschlüsselzeichenfolge erfordern HTTP v1-Sendeanforderungen ein OAuth 2.0-Zugriffstoken. Wenn Sie das Admin SDK zum Senden von Nachrichten verwenden, verwaltet die Bibliothek das Token für Sie. Wenn Sie das Raw-Protokoll verwenden, beziehen Sie das Token wie in diesem Abschnitt beschrieben und fügen Sie es als Authorization: Bearer <valid Oauth 2.0 token> zum Header hinzu.

Vor

Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA

Nach

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

Verwenden Sie abhängig von den Details Ihrer Serverumgebung eine Kombination dieser Strategien, um Serveranforderungen an Firebase-Dienste zu autorisieren:

  • Standardanmeldeinformationen für Google-Anwendungen (ADC)
  • Eine JSON-Datei für ein Dienstkonto
  • Ein kurzlebiges OAuth 2.0-Zugriffstoken, das von einem Dienstkonto abgeleitet wurde

Wenn Ihre Anwendung auf Compute Engine-, Kubernetes Engine-, App Engine- oder Cloud-Funktionen (einschließlich Cloud-Funktionen für Firebase) ausgeführt wird, verwenden Sie Application Default Credentials (ADC). ADC verwendet Ihr vorhandenes Standarddienstkonto, um Anmeldeinformationen zum Autorisieren von Anforderungen GOOGLE_APPLICATION_CREDENTIALS , und ADC ermöglicht flexible lokale Tests über die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS . Verwenden Sie ADC zusammen mit Admin SDK-Serverbibliotheken, um den Autorisierungsfluss vollständig zu automatisieren.

Wenn Ihre Anwendung in einer Nicht-Google-Serverumgebung ausgeführt wird , müssen Sie eine JSON-Datei für das Dienstkonto von Ihrem Firebase-Projekt herunterladen. Solange Sie Zugriff auf ein Dateisystem haben, das die private Schlüsseldatei enthält, können Sie mit der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS Anforderungen mit diesen manuell erhaltenen Anmeldeinformationen autorisieren. Wenn Sie keinen solchen Dateizugriff haben, müssen Sie in Ihrem Code auf die Dienstkontodatei verweisen. Dies sollte mit äußerster Vorsicht erfolgen, da das Risiko besteht, dass Ihre Anmeldeinformationen offengelegt werden.

Geben Sie Anmeldeinformationen mit ADC ein

Google Application Default Credentials (ADC) überprüft Ihre Anmeldeinformationen in der folgenden Reihenfolge:

  1. ADC prüft, ob die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS gesetzt ist. Wenn die Variable festgelegt ist, verwendet ADC die Dienstkontodatei, auf die die Variable verweist.

  2. Wenn die Umgebungsvariable nicht festgelegt ist, verwendet ADC das Standarddienstkonto, das Compute Engine, Kubernetes Engine, App Engine und Cloud-Funktionen für Anwendungen bereitstellen, die auf diesen Diensten ausgeführt werden.

  3. Wenn ADC keinen der oben genannten Anmeldeinformationen verwenden kann, gibt das System einen Fehler aus.

Das folgende Admin SDK-Codebeispiel veranschaulicht diese Strategie. In diesem Beispiel werden die Anmeldeinformationen der Anwendung nicht explizit angegeben. ADC kann die Anmeldeinformationen jedoch implizit finden, solange die Umgebungsvariable festgelegt ist oder solange die Anwendung auf Compute Engine-, Kubernetes Engine-, App Engine- oder Cloud-Funktionen ausgeführt wird.

Node.js

admin.initializeApp({
  credential: admin.credential.applicationDefault(),
});

Java

FirebaseOptions options = FirebaseOptions.builder()
    .setCredentials(GoogleCredentials.getApplicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
    .build();

FirebaseApp.initializeApp(options);

Python

default_app = firebase_admin.initialize_app()

Gehen

app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
	log.Fatalf("error initializing app: %v\n", err)
}

C #

FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.GetApplicationDefault(),
});

Geben Sie die Anmeldeinformationen manuell ein

Firebase-Projekte unterstützen Google- Dienstkonten , mit denen Sie Firebase-Server-APIs von Ihrem App-Server oder einer vertrauenswürdigen Umgebung aus aufrufen können. Wenn Sie Code lokal entwickeln oder Ihre Anwendung lokal bereitstellen, können Sie über dieses Dienstkonto erhaltene Anmeldeinformationen verwenden, um Serveranforderungen zu autorisieren.

Um ein Dienstkonto zu authentifizieren und es für den Zugriff auf Firebase-Dienste zu autorisieren, müssen Sie eine private Schlüsseldatei im JSON-Format generieren.

So generieren Sie eine private Schlüsseldatei für Ihr Dienstkonto:

  1. Öffnen Sie in der Firebase-Konsole Einstellungen> Dienstkonten .

  2. Klicken Sie auf Neuen privaten Schlüssel generieren und bestätigen Sie, indem Sie auf Schlüssel generieren klicken.

  3. Speichern Sie die JSON-Datei mit dem Schlüssel sicher.

Bei der Autorisierung über ein Dienstkonto haben Sie zwei Möglichkeiten, die Anmeldeinformationen für Ihre Anwendung bereitzustellen. Sie können entweder die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS oder den Pfad explizit an den Dienstkontoschlüssel im Code übergeben. Die erste Option ist sicherer und wird dringend empfohlen.

So legen Sie die Umgebungsvariable fest:

Setzen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf den Dateipfad der JSON-Datei, die Ihren Dienstkontoschlüssel enthält. Diese Variable gilt nur für Ihre aktuelle Shell-Sitzung. Wenn Sie also eine neue Sitzung öffnen, legen Sie die Variable erneut fest.

Linux oder MacOS

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

Windows

Mit PowerShell:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

Nachdem Sie die oben genannten Schritte ausgeführt haben, kann Application Default Credentials (ADC) Ihre Anmeldeinformationen implizit ermitteln, sodass Sie beim Testen oder Ausführen in Umgebungen, die nicht von Google stammen, Anmeldeinformationen für Dienstkonten verwenden können.

Verwenden Sie Anmeldeinformationen, um Zugriffstoken zu prägen

Verwenden Sie Ihre Firebase-Anmeldeinformationen zusammen mit der Google API-Clientbibliothek für Ihre bevorzugte Sprache, um ein kurzlebiges OAuth 2.0-Zugriffstoken abzurufen:

node.js

 function getAccessToken() {
  return new Promise(function(resolve, reject) {
    const key = require('../placeholders/service-account.json');
    const jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}

In diesem Beispiel authentifiziert die Google API-Clientbibliothek die Anforderung mit einem JSON-Web-Token oder JWT. Weitere Informationen finden Sie unter JSON-Web-Token .

Python

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token

Java

private static String getAccessToken() throws IOException {
  GoogleCredential googleCredential = GoogleCredential
      .fromStream(new FileInputStream("service-account.json"))
      .createScoped(Arrays.asList(SCOPES));
  googleCredential.refreshToken();
  return googleCredential.getAccessToken();
}

Nach Ablauf Ihres Zugriffstokens wird die Tokenaktualisierungsmethode automatisch aufgerufen, um ein aktualisiertes Zugriffstoken abzurufen.

Um den Zugriff auf FCM zu autorisieren, fordern Sie den Bereich https://www.googleapis.com/auth/firebase.messaging .

So fügen Sie das Zugriffstoken einem HTTP-Anforderungsheader hinzu:

Fügen Sie das Token als Wert des Authorization Headers im Format Authorization: Bearer <access_token> :

node.js

headers: {
  'Authorization': 'Bearer ' + accessToken
}

Python

headers = {
  'Authorization': 'Bearer ' + _get_access_token(),
  'Content-Type': 'application/json; UTF-8',
}

Java

URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;

Aktualisieren Sie die Nutzdaten der Sendeanforderungen

FCM HTTP v1 führt eine wesentliche Änderung in der Strukturierung der JSON-Nachrichtennutzdaten ein. In erster Linie stellen diese Änderungen sicher, dass Nachrichten beim Empfang auf verschiedenen Clientplattformen korrekt behandelt werden. Darüber hinaus bieten Ihnen die Änderungen zusätzliche Flexibilität beim Anpassen oder "Überschreiben" von Nachrichtenfeldern pro Plattform.

Weitere Informationen finden Sie neben dem Überprüfen der Beispiele in diesem Abschnitt unter Plattformübergreifendes Anpassen einer Nachricht und Überprüfen der API-Referenz , um sich mit HTTP v1 vertraut zu machen.

Beispiel: einfache Benachrichtigung

Hier ist ein Vergleich einer sehr einfachen Benachrichtigung payload- enthält title , body und data nur- die grundlegenden Unterschiede in Legacy - Demonstration und HTTP v1 Nutzlasten.

Vor

{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available."
  },
  "data": {
    "story_id": "story_12345"
  }
}

Nach

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
  }
}

Beispiel: Targeting mehrerer Plattformen

Um das Targeting auf mehreren Plattformen zu aktivieren, hat die Legacy-API im Backend Überschreibungen durchgeführt. Im Gegensatz dazu bietet HTTP v1 plattformspezifische Schlüsselblöcke, die Unterschiede zwischen Plattformen explizit und für den Entwickler sichtbar machen. Auf diese Weise können Sie mehrere Plattformen immer mit einer einzigen Anforderung ansprechen, wie im folgenden Beispiel gezeigt.

Vor

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// iOS
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

Nach

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

Beispiel: Anpassen mit Plattformüberschreibungen

Die HTTP v1-API vereinfacht nicht nur das plattformübergreifende Targeting von Nachrichten, sondern bietet auch Flexibilität beim Anpassen von Nachrichten pro Plattform.

Vor

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "Check out the Top Story.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// iOS
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

Nach

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY",
        "body": "Check out the Top Story"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

Weitere Beispiele und Informationen zur FCM HTTP v1-API finden Sie im Firebase-Blog .