Google: Fehlercodes

In der Anfrage muss eine gültige Fortsetzungs-URL angegeben werden.

Das Importieren von Benutzern mit Passwort-Hashes erfordert die Bereitstellung des Hashing-Algorithmus und seiner Parameter.

Der Anfrage fehlt eine Bundle-ID.

Das OAuth-Konfigurations-Client-Geheimnis ist erforderlich, um den OIDC-Codefluss zu ermöglichen.

Für den aktuellen Vorgang ist eine UID-ID erforderlich.

Der bereitgestellte Anmeldeanbieter ist für Ihr Firebase-Projekt deaktiviert. Aktivieren Sie es auf der Registerkarte Sicherheit > Authentifizierung > Anmeldemethode der Firebase-Konsole.

Die angegebene Telefonnummer wird bereits von einem vorhandenen Benutzer verwendet. Jeder Benutzer muss eine eindeutige Telefonnummer haben.

Für die Anmeldeinformationen, die zum Initialisieren der Admin-SDKs verwendet wurden, wurde kein Firebase-Projekt gefunden. Eine Dokumentation dazu, wie Sie Anmeldeinformationen für Ihr Projekt generieren und diese zur Authentifizierung der Admin-SDKs verwenden, finden Sie unter Einrichten eines Firebase-Projekts.

Ein oder mehrere benutzerdefinierte Benutzeransprüche, die für setCustomUserClaims() bereitgestellt werden, sind reserviert. Beispielsweise sollten OIDC-spezifische Ansprüche wie (sub, iat, iss, exp, aud, auth_time usw.) nicht als Schlüssel für benutzerdefinierte Ansprüche verwendet werden.

Das bereitgestellte Firebase-Sitzungscookie ist abgelaufen.

Das Firebase-Sitzungscookie wurde widerrufen.

Die Anzahl der Anfragen überschreitet die maximal zulässige Anzahl.

Die bereitgestellte UID wird bereits von einem vorhandenen Benutzer verwendet. Jeder Benutzer muss eine eindeutige UID haben.

Die Domäne der Fortsetzungs-URL steht nicht auf der Whitelist. Setzen Sie die Domäne in der Firebase-Konsole auf die Whitelist.

Das Benutzerkonto wurde von einem Administrator deaktiviert.

Es ist kein Benutzerdatensatz vorhanden, der der angegebenen Kennung entspricht.

Der Vorgang wurde abgebrochen, typischerweise aufgrund eines Parallelitätsproblems, z. B. eines Fehlers bei der Sequenzerprüfung oder eines Transaktionsabbruchs. Sehen Sie sich die Richtlinien oben an, um zwischen „FAILED_PRECONDITION“, „ABORTED“ und „UNAVAILABLE“ zu entscheiden. HTTP-Zuordnung: 409-Konflikt

Die Entität, die ein Client zu erstellen versuchte (z. B. eine Datei oder ein Verzeichnis), existiert bereits. HTTP-Zuordnung: 409-Konflikt

Der Vorgang wurde normalerweise vom Anrufer abgebrochen. HTTP-Zuordnung: 499 Client Closed Request

Nicht behebbarer Datenverlust oder Datenbeschädigung. HTTP-Zuordnung: 500 Interner Serverfehler

Die Frist lief ab, bevor der Vorgang abgeschlossen werden konnte. Bei Vorgängen, die den Zustand des Systems ändern, kann dieser Fehler auch dann zurückgegeben werden, wenn der Vorgang erfolgreich abgeschlossen wurde. Beispielsweise könnte sich eine erfolgreiche Antwort eines Servers so lange verzögert haben, dass die Frist abgelaufen ist. HTTP-Zuordnung: 504 Gateway-Timeout

Der Vorgang wurde abgelehnt, da sich das System nicht in einem für die Ausführung des Vorgangs erforderlichen Zustand befindet. Beispielsweise ist das zu löschende Verzeichnis nicht leer, ein rmdir-Vorgang wird auf ein Nichtverzeichnis angewendet usw. Dienstimplementierer können die folgenden Richtlinien verwenden, um zwischen „FAILED_PRECONDITION“, „ABORTED“ und „UNAVAILABLE“ zu entscheiden: (a) Verwenden Sie „UNAVAILABLE“, wenn der Client nur den fehlgeschlagenen Aufruf wiederholen kann. (b) Verwenden Sie „ABORTED“, wenn der Client es auf einer höheren Ebene erneut versuchen soll. Wenn beispielsweise ein vom Client angegebener Test und Satz fehlschlägt, bedeutet dies, dass der Client eine Lese-, Änderungs- und Schreibsequenz neu starten sollte. (c) Verwenden Sie „FAILED_PRECONDITION“, wenn der Client es nicht erneut versuchen soll, bis der Systemstatus explizit behoben wurde. Wenn beispielsweise ein „rmdir“ fehlschlägt, weil das Verzeichnis nicht leer ist, sollte „FAILED_PRECONDITION“ zurückgegeben werden, da der Client es nicht erneut versuchen sollte, es sei denn, die Dateien werden aus dem Verzeichnis gelöscht. HTTP-Zuordnung: 400 Bad Request

Interne Fehler. Dies bedeutet, dass einige vom zugrunde liegenden System erwartete Invarianten gebrochen wurden. Dieser Fehlercode ist schwerwiegenden Fehlern vorbehalten. HTTP-Zuordnung: 500 Interner Serverfehler

Der Client hat ein ungültiges Argument angegeben. Beachten Sie, dass sich dies von „FAILED_PRECONDITION“ unterscheidet. „INVALID_ARGUMENT“ weist auf Argumente hin, die unabhängig vom Zustand des Systems problematisch sind (z. B. ein fehlerhafter Dateiname). HTTP-Zuordnung: 400 Bad Request

Eine angeforderte Entität (z. B. Datei oder Verzeichnis) wurde nicht gefunden. Hinweis für Serverentwickler: Wenn eine Anfrage für eine ganze Benutzerklasse abgelehnt wird, z. B. bei der schrittweisen Einführung von Funktionen oder einer undokumentierten Zulassungsliste, kann „NOT_FOUND“ verwendet werden. Wenn eine Anfrage für einige Benutzer innerhalb einer Benutzerklasse abgelehnt wird, z. B. bei der benutzerbasierten Zugriffskontrolle, muss „PERMISSION_DENIED“ verwendet werden. HTTP-Zuordnung: 404 Nicht gefunden

Kein Fehler; kam mit Erfolg zurück. HTTP-Zuordnung: 200 OK

Der Vorgang wurde über den gültigen Bereich hinaus versucht. Z. B. Suchen oder Lesen über das Dateiende hinaus. Im Gegensatz zu „INVALID_ARGUMENT“ weist dieser Fehler auf ein Problem hin, das behoben werden kann, wenn sich der Systemstatus ändert. Beispielsweise generiert ein 32-Bit-Dateisystem „INVALID_ARGUMENT“, wenn es zum Lesen mit einem Offset aufgefordert wird, der nicht im Bereich [0,2^32-1] liegt, aber es generiert „OUT_OF_RANGE“, wenn es zum Lesen mit einem Offset über der aktuellen Dateigröße aufgefordert wird. Es gibt einige Überschneidungen zwischen „FAILED_PRECONDITION“ und „OUT_OF_RANGE“. Wir empfehlen die Verwendung von „OUT_OF_RANGE“ (dem spezifischeren Fehler), wenn er zutrifft, damit Aufrufer, die ein Leerzeichen durchlaufen, leicht nach einem „OUT_OF_RANGE“-Fehler suchen können, um zu erkennen, wann sie fertig sind. HTTP-Zuordnung: 400 Bad Request

Der Aufrufer verfügt nicht über die Berechtigung, den angegebenen Vorgang auszuführen. „PERMISSION_DENIED“ darf nicht für Ablehnungen verwendet werden, die durch die Erschöpfung einer Ressource verursacht werden (verwenden Sie stattdessen „RESOURCE_EXHAUSTED“ für diese Fehler). „PERMISSION_DENIED“ darf nicht verwendet werden, wenn der Anrufer nicht identifiziert werden kann (verwenden Sie stattdessen „UNAUTHENTICATED“ für diese Fehler). Dieser Fehlercode bedeutet nicht, dass die Anfrage gültig ist oder dass die angeforderte Entität existiert oder andere Vorbedingungen erfüllt. HTTP-Zuordnung: 403 Verboten

Eine Ressource ist erschöpft, möglicherweise ist ein Kontingent pro Benutzer vorhanden, oder im gesamten Dateisystem ist nicht mehr genügend Speicherplatz vorhanden. HTTP-Zuordnung: 429 Zu viele Anfragen

Die Anfrage verfügt nicht über gültige Authentifizierungsdaten für den Vorgang. HTTP-Zuordnung: 401 Nicht autorisiert

Der Dienst ist derzeit nicht verfügbar. Dies ist höchstwahrscheinlich ein vorübergehender Zustand, der durch einen erneuten Versuch mit einem Backoff behoben werden kann. Beachten Sie, dass es nicht immer sicher ist, nicht-idempotente Vorgänge zu wiederholen. Sehen Sie sich die Richtlinien oben an, um zwischen „FAILED_PRECONDITION“, „ABORTED“ und „UNAVAILABLE“ zu entscheiden. HTTP-Zuordnung: 503-Dienst nicht verfügbar

Der Vorgang ist nicht implementiert oder wird in diesem Dienst nicht unterstützt/aktiviert. HTTP-Zuordnung: 501 Nicht implementiert

Unbekannter Fehler. Dieser Fehler kann beispielsweise zurückgegeben werden, wenn ein von einem anderen Adressraum empfangener „Status“-Wert zu einem Fehlerraum gehört, der in diesem Adressraum nicht bekannt ist. Auch Fehler, die von APIs ausgelöst werden, die nicht genügend Fehlerinformationen zurückgeben, können in diesen Fehler umgewandelt werden. HTTP-Zuordnung: 500 Interner Serverfehler