Remote Config programmatisch ändern

Konfigurationsvorlagen mit dem Admin SDK, der REST API und der Firebase CLI. page_type: guide

In diesem Dokument wird beschrieben, wie Sie die Gruppe von JSON-formatierten Parametern und Bedingungen, die als Remote Config-Vorlage bezeichnet werden, programmatisch lesen und ändern können. So können Sie Vorlagenänderungen im Backend vornehmen, die die Client-App mithilfe der Clientbibliothek abrufen kann.

Mit der Remote Config REST API, den Admin SDKs oder der Firebase CLI, die in diesem Leitfaden beschrieben werden, können Sie die Verwaltung der Vorlage in der Firebase Console umgehen und Remote Config-Änderungen direkt in Ihre eigenen Prozesse einbinden. Mit Remote Config-Backend-APIs können Sie beispielsweise:

  • Remote Config-Updates planen: Wenn Sie API-Aufrufe in Verbindung mit einem Cron-Job verwenden, können Sie Remote Config-Werte regelmäßig ändern.
  • Konfigurationswerte im Batchverfahren importieren, um effizient von Ihrem eigenen proprietären System zu Firebase Remote Config zu wechseln.
  • Remote Config mit Cloud Functions for Firebase verwenden: Werte in Ihrer App basierend auf serverseitigen Ereignissen ändern. Sie können beispielsweise Remote Config verwenden, um eine neue Funktion in Ihrer App zu bewerben, und diese Werbung dann automatisch deaktivieren, sobald Sie feststellen, dass genügend Nutzer mit der neuen Funktion interagiert haben.

Diagramm, das zeigt, wie das Remote Config-Backend mit benutzerdefinierten Tools und Servern interagiert

In den folgenden Abschnitten dieses Leitfadens werden die Vorgänge beschrieben, die Sie mit den Remote Config-Backend-APIs ausführen können.

Remote Config mit dem Firebase Admin SDK ändern

Das Admin SDK ist eine Reihe von Serverbibliotheken, mit denen Sie in privilegierten Umgebungen mit Firebase interagieren können. Neben der Aktualisierung von Remote Config ermöglicht Admin SDK die Generierung und Überprüfung von Firebase-Authentifizierungstokens sowie das Lesen und Schreiben von Realtime Database. Weitere Informationen zu den Voraussetzungen und zur Einrichtung von Admin SDK finden Sie unter Firebase Admin SDK zum Server hinzufügen.

Beispielcode, der diese Aufgaben mit der Admin SDK ausführt, finden Sie in einer der folgenden Schnellstart-Apps:

In einem typischen Remote Config-Ablauf rufen Sie die aktuelle Vorlage ab, ändern einige der Parameter oder Parametergruppen und Bedingungen, validieren die Vorlage und veröffentlichen sie dann. Bevor Sie diese API-Aufrufe ausführen, müssen Sie Anfragen aus dem SDK autorisieren.

SDK initialisieren und API-Anfragen autorisieren

Wenn Sie das Admin SDK ohne Parameter initialisieren, verwendet das SDK Standardanmeldedaten für Anwendungen von Google und liest Optionen aus der Umgebungsvariable FIREBASE_CONFIG. Wenn der Inhalt der Variablen FIREBASE_CONFIG mit einem { beginnt, wird er als JSON-Objekt geparst. Andernfalls geht das SDK davon aus, dass der String der Name einer JSON-Datei mit den Optionen ist.

Beispiel:

Node.js

const admin = require('firebase-admin');
admin.initializeApp();

Java

FileInputStream serviceAccount = new FileInputStream("service-account.json");
FirebaseOptions options = FirebaseOptions.builder()
        .setCredentials(GoogleCredentials.fromStream(serviceAccount))
        .build();
FirebaseApp.initializeApp(options);

Aktuelle Remote Config-Vorlage abrufen

Remote Config-Vorlagen sind versioniert. Jede Version hat eine begrenzte Lebensdauer von 90 Tagen ab dem Zeitpunkt der Erstellung bis zum Zeitpunkt, an dem Sie sie durch ein Update ersetzen. Insgesamt können maximal 300 Versionen gespeichert werden. Weitere Informationen finden Sie unter Vorlagen und Versionsverwaltung.

Mit den Backend-APIs können Sie die aktuelle aktive Version der Remote Config-Vorlage im JSON-Format abrufen.

Parameter und Parameterwerte, die speziell als Varianten in einem A/B Testing-Test erstellt wurden, sind nicht in exportierten Vorlagen enthalten.

So rufen Sie die Vorlage ab:

Node.js

function getTemplate() {
  var config = admin.remoteConfig();
  config.getTemplate()
      .then(function (template) {
        console.log('ETag from server: ' + template.etag);
        var templateStr = JSON.stringify(template);
        fs.writeFileSync('config.json', templateStr);
      })
      .catch(function (err) {
        console.error('Unable to get template');
        console.error(err);
      });
}

Java

Template template = FirebaseRemoteConfig.getInstance().getTemplateAsync().get();
// See the ETag of the fetched template.
System.out.println("ETag from server: " + template.getETag());

Remote Config-Parameter ändern

Sie können Remote Config Parameter und Parametergruppen programmatisch ändern und hinzufügen. Sie können beispielsweise einer vorhandenen Parametergruppe mit dem Namen „new_menu“ einen Parameter hinzufügen, um die Anzeige saisonaler Informationen zu steuern:

Node.js

function addParameterToGroup(template) {
  template.parameterGroups['new_menu'].parameters['spring_season'] = {
    defaultValue: {
      useInAppDefault: true
    },
    description: 'spring season menu visibility.',
  };
}

Java

template.getParameterGroups().get("new_menu").getParameters()
        .put("spring_season", new Parameter()
                .setDefaultValue(ParameterValue.inAppDefault())
                .setDescription("spring season menu visibility.")
        );

Mit der API können Sie neue Parameter und Parametergruppen erstellen oder Standardwerte, bedingte Werte und Beschreibungen ändern. In jedem Fall müssen Sie die Vorlage nach Änderungen explizit veröffentlichen.

Remote Config-Bedingungen ändern

Sie können Remote Config-Bedingungen und bedingte Werte programmatisch ändern und hinzufügen. So fügen Sie beispielsweise eine neue Bedingung hinzu:

Node.js

function addNewCondition(template) {
  template.conditions.push({
    name: 'android_en',
    expression: 'device.os == \'android\' && device.country in [\'us\', \'uk\']',
    tagColor: 'BLUE',
  });
}

Java

template.getConditions().add(new Condition("android_en",
        "device.os == 'android' && device.country in ['us', 'uk']", TagColor.BLUE));

In jedem Fall müssen Sie die Vorlage nach Änderungen explizit veröffentlichen.

Die Remote Config-Backend-APIs bieten verschiedene Bedingungen und Vergleichsoperatoren, mit denen Sie das Verhalten und die Darstellung Ihrer App ändern können. Weitere Informationen zu Bedingungen und den für diese Bedingungen unterstützten Operatoren finden Sie in der Referenz zu bedingten Ausdrücken.

Remote Config-Vorlage validieren

Optional können Sie Ihre Änderungen vor der Veröffentlichung validieren, wie unten dargestellt:

Node.js

function validateTemplate(template) {
  admin.remoteConfig().validateTemplate(template)
      .then(function (validatedTemplate) {
        // The template is valid and safe to use.
        console.log('Template was valid and safe to use');
      })
      .catch(function (err) {
        console.error('Template is invalid and cannot be published');
        console.error(err);
      });
}

Java

try {
  Template validatedTemplate = FirebaseRemoteConfig.getInstance()
          .validateTemplateAsync(template).get();
  System.out.println("Template was valid and safe to use");
} catch (ExecutionException e) {
  if (e.getCause() instanceof FirebaseRemoteConfigException) {
    FirebaseRemoteConfigException rcError = (FirebaseRemoteConfigException) e.getCause();
    System.out.println("Template is invalid and cannot be published");
    System.out.println(rcError.getMessage());
  }
}

Bei diesem Validierungsprozess wird nach Fehlern wie doppelten Schlüsseln für Parameter und Bedingungen, ungültigen oder nicht vorhandenen Bedingungsnamen oder falsch formatierten ETags gesucht. Wenn eine Anfrage beispielsweise mehr als die zulässige Anzahl von Schlüsseln (2.000) enthält, wird die Fehlermeldung Param count too large zurückgegeben.

Vorlage Remote Config veröffentlichen

Nachdem Sie eine Vorlage abgerufen und mit Ihren Änderungen überarbeitet haben, können Sie sie veröffentlichen. Wenn Sie eine Vorlage wie in diesem Abschnitt beschrieben veröffentlichen, wird die gesamte vorhandene Konfigurationsvorlage durch die aktualisierte Datei ersetzt. Der neuen aktiven Vorlage wird eine Versionsnummer zugewiesen, die um eins höher ist als die der Vorlage, die sie ersetzt hat.

Bei Bedarf können Sie die REST API verwenden, um ein Rollback auf die vorherige Version durchzuführen. Um das Risiko von Fehlern bei einem Update zu verringern, können Sie vor der Veröffentlichung eine Validierung durchführen.

Remote Config-Personalisierungen und ‑Bedingungen sind in heruntergeladenen Vorlagen enthalten. Daher ist es wichtig, die folgenden Einschränkungen zu beachten, wenn Sie versuchen, in einem anderen Projekt zu veröffentlichen:

  • Personalisierungen können nicht von einem Projekt in ein anderes importiert werden.

    Wenn Sie beispielsweise Personalisierungen in Ihrem Projekt aktiviert haben und eine Vorlage herunterladen und bearbeiten, können Sie sie im selben Projekt veröffentlichen. Sie können sie jedoch nicht in einem anderen Projekt veröffentlichen, es sei denn, Sie löschen die Personalisierungen aus der Vorlage.

  • Bedingungen können von Projekt zu Projekt importiert werden. Beachten Sie jedoch, dass alle spezifischen bedingten Werte (z. B. App-IDs oder Zielgruppen) im Zielprojekt vorhanden sein müssen, bevor Sie sie veröffentlichen.

    Wenn Sie beispielsweise einen Remote Config-Parameter mit einer Bedingung haben, die den Plattformwert iOS angibt, kann die Vorlage in einem anderen Projekt veröffentlicht werden, da Plattformwerte für alle Projekte gleich sind. Wenn sie jedoch eine Bedingung enthält, die auf einer bestimmten App-ID oder Nutzerzielgruppe basiert, die im Zielprojekt nicht vorhanden ist, schlägt die Validierung fehl.

  • Wenn die Vorlage, die Sie veröffentlichen möchten, Bedingungen enthält, die auf Google Analytics basieren, muss Analytics im Zielprojekt aktiviert sein.

Node.js

function publishTemplate() {
  var config = admin.remoteConfig();
  var template = config.createTemplateFromJSON(
      fs.readFileSync('config.json', 'UTF8'));
  config.publishTemplate(template)
      .then(function (updatedTemplate) {
        console.log('Template has been published');
        console.log('ETag from server: ' + updatedTemplate.etag);
      })
      .catch(function (err) {
        console.error('Unable to publish template.');
        console.error(err);
      });
}

Java

try {
  Template publishedTemplate = FirebaseRemoteConfig.getInstance()
          .publishTemplateAsync(template).get();
  System.out.println("Template has been published");
  // See the ETag of the published template.
  System.out.println("ETag from server: " + publishedTemplate.getETag());
} catch (ExecutionException e) {
  if (e.getCause() instanceof FirebaseRemoteConfigException) {
    FirebaseRemoteConfigException rcError = (FirebaseRemoteConfigException) e.getCause();
    System.out.println("Unable to publish template.");
    System.out.println(rcError.getMessage());
  }
}

Remote Config mit der REST API ändern

In diesem Abschnitt werden die wichtigsten Funktionen der Remote Config REST API unter https://firebaseremoteconfig.googleapis.com beschrieben. Ausführliche Informationen finden Sie in der API-Referenz.

Zugriffstoken zum Authentifizieren und Autorisieren von API-Anfragen abrufen

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 mit den Anmeldedaten, die Sie mit diesem Dienstkonto erhalten haben, Serveranfragen autorisieren.

Alle Dienstkonten für Ihr Firebase-Projekt finden Sie in den Einstellungen auf dem Tab Dienstkonten.

Um ein Dienstkonto zu authentifizieren und ihm den Zugriff auf Firebase-Dienste zu autorisieren, müssen Sie eine Datei mit dem privaten Schlüssel im JSON-Format generieren.

So erstellen Sie eine Datei mit dem privaten Schlüssel für Ihr Dienstkonto:

  1. Rufen Sie in der Firebase Console die Einstellungen > Dienstkonten auf.

  2. Klicke auf Neuen privaten Schlüssel generieren und bestätige die Aktion mit einem Klick auf Schlüssel generieren.

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

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

So legen Sie die Umgebungsvariable fest:

Legen Sie für die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS den Dateipfad der JSON-Datei fest, die Ihren Dienstkontoschlüssel enthält. Diese Variable gilt nur für Ihre aktuelle Shell-Sitzung. Wenn Sie eine neue Sitzung öffnen, müssen Sie die Variable noch einmal festlegen.

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, können Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) Ihre Anmeldedaten implizit ermitteln. So können Sie Anmeldedaten für Dienstkonten verwenden, wenn Sie in Nicht-Google-Umgebungen testen oder ausführen.

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

Node.js

 function getAccessToken() {
  return admin.credential.applicationDefault().getAccessToken()
      .then(accessToken => {
        return accessToken.access_token;
      })
      .catch(err => {
        console.error('Unable to get access token');
        console.error(err);
      });
}

In diesem Beispiel authentifiziert die Google API-Clientbibliothek die Anfrage mit einem JSON-Webtoken (JWT). Weitere Informationen finden Sie unter JSON-Webtokens.

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

public static String getAccessToken() throws IOException {
  GoogleCredentials googleCredentials = GoogleCredentials
          .fromStream(new FileInputStream("service-account.json"))
          .createScoped(Arrays.asList(SCOPES));
  googleCredentials.refreshAccessToken();
  return googleCredentials.getAccessToken().getTokenValue();
}

Nachdem Ihr Zugriffstoken abgelaufen ist, wird die Methode zum Aktualisieren des Tokens automatisch aufgerufen, um ein aktualisiertes Zugriffstoken abzurufen.

Wenn Sie den Zugriff auf Remote Config autorisieren möchten, fordern Sie den Bereich https://www.googleapis.com/auth/firebase.remoteconfig an.

Vorlage Remote Config ändern

Wenn Sie mit Remote Config-Vorlagen arbeiten, sollten Sie beachten, dass sie versioniert sind und jede Version eine begrenzte Lebensdauer hat: 90 Tage ab dem Zeitpunkt der Erstellung bis zum Zeitpunkt, an dem Sie sie durch ein Update ersetzen. Es können maximal 300 Versionen gespeichert werden. Weitere Informationen finden Sie unter Vorlagen und Versionsverwaltung.

Aktuelle Remote Config-Vorlage abrufen

Mit den Backend-APIs können Sie die aktuelle aktive Version der Remote Config-Vorlage im JSON-Format abrufen.

Parameter und Parameterwerte, die speziell als Varianten in einem A/B Testing-Test erstellt wurden, sind nicht in exportierten Vorlagen enthalten.

Verwenden Sie die folgenden Befehle:

cURL

curl --compressed -D headers -H "Authorization: Bearer token" -X GET https://firebaseremoteconfig.googleapis.com/v1/projects/my-project-id/remoteConfig -o filename

Mit diesem Befehl wird die JSON-Nutzlast in eine Datei und die Header (einschließlich des E-Tags) in eine separate Datei ausgegeben.

Roh-HTTP-Anfrage

Host: firebaseremoteconfig.googleapis.com

GET /v1/projects/my-project-id/remoteConfig HTTP/1.1
Authorization: Bearer token
Accept-Encoding: gzip

Dieser API-Aufruf gibt das folgende JSON-Objekt zurück, zusammen mit einem separaten Header, der ein ETag enthält, das Sie für die nachfolgende Anfrage verwenden.

Remote Config-Vorlage validieren

Optional können Sie Ihre Aktualisierungen vor der Veröffentlichung validieren. Sie können Vorlagenaktualisierungen validieren, indem Sie der Veröffentlichungsanfrage den URL-Parameter ?validate_only=true hinzufügen. In der Antwort bedeutet der Statuscode 200 und ein aktualisiertes ETag mit dem Suffix -0, dass die Aktualisierung erfolgreich validiert wurde. Jede Antwort, die nicht mit dem Statuscode 200 zurückgegeben wird, weist darauf hin, dass die JSON-Daten Fehler enthalten, die Sie vor der Veröffentlichung korrigieren müssen.

Remote Config-Vorlage aktualisieren

Nachdem Sie eine Vorlage abgerufen und den JSON-Inhalt mit Ihren Änderungen überarbeitet haben, können Sie sie veröffentlichen. Wenn Sie eine Vorlage wie in diesem Abschnitt beschrieben veröffentlichen, wird die gesamte vorhandene Konfigurationsvorlage durch die aktualisierte Datei ersetzt. Der neuen aktiven Vorlage wird eine Versionsnummer zugewiesen, die um eins höher ist als die der Vorlage, die sie ersetzt hat.

Bei Bedarf können Sie mit der REST API ein Rollback auf die vorherige Version durchführen. Um das Risiko von Fehlern bei einem Update zu verringern, können Sie vor der Veröffentlichung eine Validierung durchführen.

Remote Config-Personalisierungen und ‑Bedingungen sind in heruntergeladenen Vorlagen enthalten. Daher ist es wichtig, die folgenden Einschränkungen zu beachten, wenn Sie versuchen, in einem anderen Projekt zu veröffentlichen:

  • Personalisierungen können nicht von einem Projekt in ein anderes importiert werden.

    Wenn Sie beispielsweise Personalisierungen in Ihrem Projekt aktiviert haben und eine Vorlage herunterladen und bearbeiten, können Sie sie im selben Projekt veröffentlichen. Sie können sie jedoch nicht in einem anderen Projekt veröffentlichen, es sei denn, Sie löschen die Personalisierungen aus der Vorlage.

  • Bedingungen können von Projekt zu Projekt importiert werden. Beachten Sie jedoch, dass alle spezifischen bedingten Werte (z. B. App-IDs oder Zielgruppen) im Zielprojekt vorhanden sein müssen, bevor Sie sie veröffentlichen.

    Wenn Sie beispielsweise einen Remote Config-Parameter mit einer Bedingung haben, die den Plattformwert iOS angibt, kann die Vorlage in einem anderen Projekt veröffentlicht werden, da Plattformwerte für alle Projekte gleich sind. Wenn sie jedoch eine Bedingung enthält, die auf einer bestimmten App-ID oder Nutzerzielgruppe basiert, die im Zielprojekt nicht vorhanden ist, schlägt die Validierung fehl.

  • Wenn die Vorlage, die Sie veröffentlichen möchten, Bedingungen enthält, die auf Google Analytics basieren, muss Analytics im Zielprojekt aktiviert sein.

cURL

curl --compressed -H "Content-Type: application/json; UTF8" -H "If-Match: last-returned-etag" -H "Authorization: Bearer token" -X PUT https://firebaseremoteconfig.googleapis.com/v1/projects/my-project-id/remoteConfig -d @filename

Für diesen curl-Befehl können Sie den Inhalt mit dem Zeichen „@“ gefolgt vom Dateinamen angeben.

Roh-HTTP-Anfrage

Host: firebaseremoteconfig.googleapis.com
PUT /v1/projects/my-project-id/remoteConfig HTTP/1.1
Content-Length: size
Content-Type: application/json; UTF8
Authorization: Bearer token
If-Match: expected ETag
Accept-Encoding: gzip
JSON_HERE

Da es sich um eine Schreibanfrage handelt, wird das ETag durch diesen Befehl geändert und ein aktualisiertes ETag wird in den Antwortheadern des nächsten PUT-Befehls bereitgestellt.

Remote Config-Bedingungen ändern

Sie können Remote Config-Bedingungen und bedingte Werte programmatisch ändern. Mit der REST API müssen Sie die Vorlage direkt bearbeiten, um Bedingungen zu ändern, bevor Sie die Vorlage veröffentlichen.

{
  "conditions": [{
    "name": "android_english",
    "expression": "device.os == 'android' && device.country in ['us', 'uk']",
    "tagColor": "BLUE"
  }, {
    "name": "tenPercent",
    "expression": "percent <= 10",
    "tagColor": "BROWN"
  }],
  "parameters": {
    "welcome_message": {
      "defaultValue": {
        "value": "Welcome to this sample app"
      },
      "conditionalValues": {
        "tenPercent": {
          "value": "Welcome to this new sample app"
        }
      },
      "description": "The sample app's welcome message"
    },
    "welcome_message_caps": {
      "defaultValue": {
        "value": "false"
      },
      "conditionalValues": {
        "android_english": {
          "value": "true"
        }
      },
      "description": "Whether the welcome message should be displayed in all
      capital letters."
    }
  }
}

In den Änderungen im vorherigen Snippet wird zuerst eine Reihe von Bedingungen und dann für jeden Parameter ein Standardwert und ein bedingter Parameterwert (bedingte Werte) definiert. Außerdem fügen sie eine optionale Beschreibung für jedes Element hinzu. Wie Codekommentare sind diese für Entwickler gedacht und werden nicht in der App angezeigt. Für die Versionsverwaltung wird auch ein ETag bereitgestellt.

Die Remote Config-Backend-APIs bieten verschiedene Bedingungen und Vergleichsoperatoren, mit denen Sie das Verhalten und die Darstellung Ihrer App ändern können. Weitere Informationen zu Bedingungen und den für diese Bedingungen unterstützten Operatoren finden Sie in der Referenz zu bedingten Ausdrücken.

HTTP-Fehlercodes

Statuscode Bedeutung
200 Erfolgreich aktualisiert
400 Es ist ein Validierungsfehler aufgetreten. Wenn eine Anfrage beispielsweise mehr als die zulässige Anzahl von Schlüsseln (2.000) enthält, wird der Fehlercode „400“ (Bad Request) mit der Fehlermeldung Param count too large zurückgegeben. Dieser HTTPS-Statuscode kann auch in den folgenden beiden Situationen auftreten:
  • Es ist ein Fehler aufgrund einer Versionsabweichung aufgetreten, weil die Gruppe von Werten und Bedingungen aktualisiert wurde, seit Sie das letzte Mal einen ETag-Wert abgerufen haben. Verwenden Sie zur Behebung dieses Problems den Befehl GET, um eine neue Vorlage und einen neuen ETag-Wert abzurufen, aktualisieren Sie die Vorlage und senden Sie sie dann mit dieser Vorlage und dem neuen ETag-Wert ein.
  • Der Befehl PUT (Aktualisierungsanfrage für die Vorlage Remote Config) wurde ohne Angabe eines If-Match-Headers ausgeführt.
401 Es ist ein Autorisierungsfehler aufgetreten (es wurde kein Zugriffstoken angegeben oder die Firebase Remote Config REST API wurde Ihrem Projekt in der Cloud Developer Console nicht hinzugefügt).
403 Es ist ein Authentifizierungsfehler aufgetreten (das falsche Zugriffstoken wurde angegeben)
500 Ein interner Fehler ist aufgetreten. Wenn dieser Fehler auftritt, reichen Sie ein Firebase-Support-Ticket ein.

Ein Statuscode von 200 bedeutet, dass die Remote Config-Vorlage (Parameter, Werte und Bedingungen für das Projekt) aktualisiert wurde und jetzt für Apps verfügbar ist, die dieses Projekt verwenden. Andere Statuscodes weisen darauf hin, dass die zuvor vorhandene Remote Config-Vorlage weiterhin gültig ist.

Nachdem Sie Aktualisierungen an Ihrer Vorlage vorgenommen haben, können Sie in der Firebase-Konsole prüfen, ob die Änderungen wie erwartet angezeigt werden. Das ist wichtig, da sich die Reihenfolge der Bedingungen darauf auswirkt, wie sie ausgewertet werden. Die erste Bedingung, die true ergibt, wird angewendet.

ETag-Verwendung und erzwungene Updates

Die Remote Config REST API verwendet ein Entity-Tag (ETag), um Race Conditions und sich überschneidende Aktualisierungen von Ressourcen zu verhindern. Weitere Informationen zu ETags finden Sie unter ETag – HTTP.

Für die REST API empfiehlt Google, das ETag zu cachen, das vom letzten GET-Befehl bereitgestellt wurde, und diesen ETag-Wert im If-Match-Anfrageheader zu verwenden, wenn PUT-Befehle ausgegeben werden. Wenn Ihr PUT-Befehl den HTTPS-Statuscode 409 zurückgibt, sollten Sie einen neuen GET-Befehl ausführen, um ein neues ETag und eine neue Vorlage für den nächsten PUT-Befehl zu erhalten.

Sie können das ETag und den damit verbundenen Schutz umgehen, indem Sie die Aktualisierung der Remote Config-Vorlage erzwingen: If-Match: *. Dieser Ansatz wird jedoch nicht empfohlen, da er das Risiko birgt, dass Updates für Ihre Remote Config-Vorlage verloren gehen, wenn mehrere Clients die Remote Config-Vorlage aktualisieren. Diese Art von Konflikt kann auftreten, wenn mehrere Clients die API verwenden oder wenn es zu widersprüchlichen Aktualisierungen von API-Clients und Firebase-Konsolennutzern kommt.

Eine Anleitung zum Verwalten von Remote Config-Vorlagenversionen finden Sie unter Remote Config-Vorlagen und Versionsverwaltung.

Remote Config mit der Firebase-CLI ändern

Mit der Firebase-Befehlszeile können Sie Remote Config-Vorlagen prüfen, verwalten und zurücksetzen sowie Remote Config-Tests und ‑Rollouts direkt über die Befehlszeile auflisten, prüfen und löschen.

Voraussetzungen und Einrichtung

  1. Installieren Sie die Firebase CLI oder aktualisieren Sie sie auf die neueste Version.

  2. Melden Sie sich in Firebase an:

    firebase login
  3. Legen Sie Ihr aktives Projekt fest oder geben Sie --project PROJECT_ID bei jedem Befehl an:

    firebase use PROJECT_ID

Prüfen Sie, ob Ihr Konto oder Dienstkonto die erforderlichen IAM-Berechtigungen hat:

Zusammenfassung der Befehlszeilenbefehle

Befehl Beschreibung
firebase remoteconfig:versions:list Hier werden die letzten Remote Config-Vorlagenversionen aufgeführt.
firebase remoteconfig:get Ruft eine Remote Config-Vorlage ab (optional wird in eine Datei geschrieben).
firebase remoteconfig:rollback Führt ein Rollback der Vorlage Remote Config auf eine vorherige Version durch.
firebase remoteconfig:experiments:list Listet alle Remote Config-Tests im Projekt auf.
firebase remoteconfig:experiments:get Ruft Details zu einem bestimmten Remote Config-Test ab.
firebase remoteconfig:experiments:delete Löscht einen bestimmten Remote Config-Test.
firebase remoteconfig:rollouts:list Listet alle Remote Config-Roll-outs im Projekt auf.
firebase remoteconfig:rollouts:get Ruft Details zu einem bestimmten Remote Config-Rollout ab.
firebase remoteconfig:rollouts:delete Löscht ein bestimmtes Remote Config-Roll-out.

Remote Config-Vorlagen und ‑Versionen ändern

Mit den folgenden Befehlen können Sie Remote Config-Vorlagen und ihren Versionsverlauf prüfen, herunterladen und zurücksetzen:

Vorlagenversionen auflisten

Hier werden standardmäßig die 10 neuesten Versionen der Vorlage Remote Config aufgeführt, einschließlich der Versionsnummer, der Aktualisierungszeit, des Aktualisierungsursprungs, des Aktualisierungstyps und updateUser.

firebase remoteconfig:versions:list [--limit NUMBER_OF_VERSIONS]
  • --limit NUMBER_OF_VERSIONS: Die maximale Anzahl der zurückzugebenden Versionen. Geben Sie 0 an, um alle vorhandenen Versionen zurückzugeben (bis zum Limit von 300 gespeicherten Versionen).

Beispiele:

  • Die zehn letzten Versionen auflisten:

    firebase remoteconfig:versions:list
  • Alle verfügbaren Versionen auflisten:

    firebase remoteconfig:versions:list --limit 0
  • Die fünf neuesten Versionen auflisten:

    firebase remoteconfig:versions:list --limit 5

Vorlage abrufen

Ruft die Remote Config-Vorlage ab und gibt die Parametergruppen, Parameter, Bedingungsnamen und die Version aus. Standardmäßig wird die aktuelle aktive Version abgerufen und eine formatierte Zusammenfassung im Terminal ausgegeben.

firebase remoteconfig:get [-v, --version_number VERSION_NUMBER] [-o, --output FILENAME]
  • -v, --version_number VERSION_NUMBER: Die Versionsnummer der abzurufenden Vorlage. Wenn keine Angabe gemacht wird, lautet die Standardeinstellung die neueste Version.
  • -o, --output FILENAME: Schreibt die JSON-Nutzlast der Vorlage direkt in den angegebenen Pfad, anstatt sie in stdout auszugeben.

Beispiele:

  • Aktive Vorlage im Terminal anzeigen:

    firebase remoteconfig:get
  • Laden Sie die aktuelle aktive Vorlage in eine JSON-Datei herunter:

    firebase remoteconfig:get -o remote_config_template.json
  • So laden Sie eine bestimmte frühere Version (z. B. Version 12) in eine Datei herunter:

    firebase remoteconfig:get -v 12 -o remote_config_v12.json

Rollback einer Vorlage durchführen

Führt ein Rollback der aktiven Remote Config-Vorlage auf eine vorherige Version durch. Dadurch wird eine neue aktive Version erstellt, deren Inhalt mit dem der Zielversion identisch ist.

firebase remoteconfig:rollback [-v, --version_number VERSION_NUMBER] [--force]
  • -v, --version_number VERSION_NUMBER: Die Zielversionsnummer, auf die ein Rollback ausgeführt werden soll. Wenn keine Angabe erfolgt, wird standardmäßig die unmittelbar vorhergehende Version verwendet (aktuelle Version minus 1).
  • --force: Führt den Rollback sofort aus, ohne dass eine interaktive Bestätigung (Y/N) erforderlich ist. Nützlich für CI/CD-Pipelines und automatisierte Skripts.

Beispiele:

  • Rollback auf die vorherige Version mit interaktiver Bestätigung durchführen:

    firebase remoteconfig:rollback
  • Rollback auf Version 8 ohne Aufforderung durchführen:

    firebase remoteconfig:rollback -v 8 --force

A/B Testing-Tests ändern

Mit den folgenden Befehlen können Sie Remote Config-A/B Testing-Tests direkt über die CLI auflisten, prüfen und löschen:

Tests auflisten

Listet alle Remote Config-Tests für das Projekt mit optionaler Filterung und Paginierung auf.

firebase remoteconfig:experiments:list [--filter EXPRESSION] [--pageSize NUMBER] [--pageToken TOKEN]
  • --filter EXPRESSION: Filterausdruck, der auf die Testliste angewendet werden soll.
  • --pageSize NUMBER: Anzahl der zurückzugebenden Tests pro Seite (Standardwert: 10).
  • --pageToken TOKEN: Token für den Seitenoffset beim Abrufen von paginierten Ergebnissen.

Beispiel:

firebase remoteconfig:experiments:list

Testdetails abrufen

Ruft die vollständigen Details für einen angegebenen Remote Config-Test ab.

firebase remoteconfig:experiments:get EXPERIMENT_ID

Beispiel:

firebase remoteconfig:experiments:get exp_promo_discount_2026

Test löschen

Löscht den angegebenen Remote Config-Test.

firebase remoteconfig:experiments:delete EXPERIMENT_ID

Beispiel:

firebase remoteconfig:experiments:delete exp_promo_discount_2026

Remote Config-Roll-outs ändern

Verwenden Sie die folgenden Befehle, um Remote Config-Roll-outs direkt mit der CLI aufzulisten, zu prüfen und zu löschen:

Roll-outs auflisten

Listet alle Remote Config-Rollouts für das Projekt auf, mit optionaler Filterung und Paginierung.

firebase remoteconfig:rollouts:list [--filter EXPRESSION] [--pageSize NUMBER] [--pageToken TOKEN]
  • --filter EXPRESSION: Filterausdruck, der auf die Rollout-Liste angewendet werden soll.
  • --pageSize NUMBER: Anzahl der Rollouts, die pro Seite zurückgegeben werden sollen (Standardwert: 10).
  • --pageToken TOKEN: Token für den Seitenoffset beim Abrufen von paginierten Ergebnissen.

Beispiel:

firebase remoteconfig:rollouts:list

Roll-out-Details abrufen

Ruft die vollständigen Details für einen angegebenen Remote Config-Rollout ab.

firebase remoteconfig:rollouts:get ROLLOUT_ID

Beispiel:

firebase remoteconfig:rollouts:get rollout_new_checkout_flow

Roll-out löschen

Löscht das angegebene Remote Config-Rollout.

firebase remoteconfig:rollouts:delete ROLLOUT_ID

Beispiel:

firebase remoteconfig:rollouts:delete rollout_new_checkout_flow

Allgemeine Informationen zu Firebase-CLI-Befehlen finden Sie in der Firebase-CLI-Referenz.