Freigeben über

Problembehandlung bei der Verwendung des Daten-API-Generators für Azure-Datenbanken

  • Artikel

Dieser Artikel enthält Lösungen für häufige Fehler, die auftreten können, wenn Sie den Daten-API-Generator für Azure-Datenbanken verwenden.

Generischer Endpunkt: HTTP 400 "Ungültige Anforderung" Fehler

In den folgenden Abschnitten werden die Ursachen und Lösungen für den HTTP 400 -Fehler "Ungültige Anforderung" beschrieben.

Ungültiger Endpunkt des Daten-API-Generators

Die Basis der URL-Pfadkomponente ist dem REST- oder GraphQL-Endpunkt des Daten-API-Generators zugeordnet. Wenn die Basis der URL-Pfadkomponente nicht mit dem in der Laufzeitkonfiguration des Daten-API-Generators festgelegten Wert übereinstimmt, gibt der Daten-API-Generator einen HTTP 400 -Fehler "Ungültige Anforderung" zurück.

Sie können die Stammpfade für die GraphQL- und REST-Endpunkte im runtime Abschnitt der Laufzeitkonfiguration des Daten-API-Generators konfigurieren. Sie müssen die Werte verwenden, um die URL-Pfade für die REST- und GraphQL-Endpunkte zu beginnen.

Die folgenden Konfigurationssätze werden beispielsweise als Stammpfad des REST-Endpunkts und /graphql als Stamm des GraphQL-Endpunkts festgelegt/api:

"runtime": {
    "rest": {
      "enabled": true,
      "path": "/api"
    },
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "...",
}

Die Werte, die Sie am Anfang der URL-Pfade für die REST- und GraphQL-Endpunkte verwenden müssen, sind:

/api/<entity>

/graphql

Notiz

Beim Verwenden des Daten-API-Generators mit dem statischen Web-Apps mithilfe des Features "Datenbankverbindungen" beginnt der URL-Pfad mit /data-api. Sie können den Wert Ihres gewünschten Endpunkts nach diesem Wert hinzufügen. Beispiel /data-api/api/<entity> : für REST und /data-api/graphql für GraphQL.

Konfiguration von statischen Web-Apps Datenbankverbindungen

Wenn Sie den Daten-API-Generator mit dem Feature "Static Web-Apps Database Connections" verwenden, tritt der Fehler "Antwortstatuscode weist nicht auf Erfolg hin: 400 (Ungültige Anforderung)" im Antworttext:

{"Message":"{\u0022Message\u0022:\u0022Response status code does not indicate success: 400 (Bad Request).\u0022,\u0022ActivityId\u0022:\u0022<GUID>\u0022}","ActivityId":"<GUID>"}

Dieser Fehler kann auf ein Problem mit der Konfiguration hinweisen, die Sie beim Verknüpfen der Datenbank angegeben haben.

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

  1. Überprüfen Sie, ob Ihre Datenbankanmeldeinformationen in einem Tool wie Azure Data Studio oder SQL Server Management Studio (SSMS) gültig sind.
  2. Aufheben der Verknüpfung/Erneute Verknüpfung der verbundenen Datenbank.

Wenn der Fehler weiterhin auftritt, stellen Sie sicher, dass Sie Azure-Dienste und -Ressourcen für den Zugriff auf diesen Server für die Ausnahmen auf der Netzwerkseite Ihrer Azure-Datenbankressource auswählen. Mit dieser Option wird die Firewall so konfiguriert, dass Verbindungen von IP-Adressen zugelassen werden, die jedem Azure-Dienst oder -Objekt zugeordnet sind, einschließlich Verbindungen aus den Abonnements anderer Kunden.

Screenshot des Kontrollkästchens

REST-Endpunkt: HTTP 404 "Nicht gefunden" Fehler

Wenn die angeforderte URL auf eine Route verweist, die keiner Entität zugeordnet ist, wird ein HTTP 404-Fehler zurückgegeben. Standardmäßig ist der Name der Entität auch der Routenname. Wenn Sie beispielsweise die Beispielentität Todo in der Konfigurationsdatei wie im folgenden Beispiel konfigurieren:

"Todo": {
      "source": "dbo.todos",
      "...": "..."
    }

Anschließend ist die Todo Entität über die folgende Route erreichbar:

/<rest-route>/Todo

Wenn Sie die rest.path Eigenschaft in der Entitätskonfiguration angeben, todowie im folgenden Beispiel gezeigt:

"Todo": {
    "source": "dbo.todos",
    "rest": {
      "path": "todo"
    },
    "...": "..."
  }

Anschließend lautet die URL-Route für die Todo Entität , wobei alle Kleinbuchstaben mit dem genauen Wert übereinstimmen, der in der Laufzeitkonfiguration definiert ist todo:

/<rest-route>/todo

GraphQL-Endpunkt: HTTP 400 "Ungültige Anforderung" Fehler

Eine GraphQL-Anforderung führt jedes Mal, wenn die GraphQL-Anforderung falsch erstellt wird, zu einem HTTP 400 -Fehler "Ungültige Anforderung". Dies kann auf ein nicht vorhandenes Entitätsfeld oder einen falsch geschriebenen Entitätsnamen zurückzuführen sein. Der Daten-API-Generator gibt einen beschreibenden Fehler und Fehlerdetails in der Antwortnutzlast zurück.

Wenn Sie eine GET Anforderung an den GraphQL-Endpunkt senden, gibt der Antworttext des zurückgegebenen Fehlers "Entweder die Parameterabfrage oder die Parameter-ID muss festgelegt werden." Stellen Sie sicher, dass Sie Ihre GraphQL-Anforderungen mit HTTP POSTsenden.

GraphQL-Endpunkt: HTTP 404 "Nicht gefunden" Fehler

Stellen Sie sicher, dass die GraphQL-Anforderung mithilfe der HTTP-Methode an den konfigurierten GraphQL-Endpunkt POST gesendet wird. Standardmäßig ist /graphqldie GraphQL-Endpunktroute .

GraphQL-Endpunkt: "Die Objekttypabfrage muss mindestens ein Feld definieren, um gültig zu sein"

Wenn beim Start des Daten-API-Generators ein GraphQL-Schema basierend auf Ihrer Laufzeitkonfiguration nicht generiert werden kann, wird die Fehlermeldung angezeigt:

Die Objekttypabfrage muss mindestens ein Feld definieren, um gültig zu sein.

Für die GraphQL-Spezifikation muss mindestens ein Query Objekt im GraphQL-Schema definiert werden. Sie müssen überprüfen, ob Ihre Laufzeitkonfiguration eine der folgenden Bedingungen erfüllt:

  • Die read Aktion wird für mindestens eine GraphQL-fähige Entität definiert. GraphQL ist standardmäßig für Entitäten aktiviert. Stellen Sie daher sicher, dass Sie diese Entschärfung nicht auf eine Entität anwenden, die mit {"graphql": false}.

  • Wenn Sie nur gespeicherte Prozeduren verfügbar machen, definieren Sie { "graphql": { "operation": query" } } diese für mindestens eine gespeicherte Prozedurenentität, die den GraphQL-Vorgangstyp mutationder standardmäßigen gespeicherten Prozedur überschreibt.

    Sie müssen über mindestens eine gespeicherte Prozedur verfügen, die nur die Daten liest und nicht ändert. Andernfalls schlägt die GraphQL-Schemagenerierung aufgrund eines leeren query Felds im Schema fehl.

GraphQL-Endpunkt: Introspection funktioniert nicht mit dem GraphQL-Endpunkt

Tools, die GraphQL unterstützen, verwenden normalerweise die GraphQL-Schemaintrospection, ohne dass zusätzliche Einrichtung erforderlich ist. Stellen Sie sicher, dass Sie die Laufzeitkonfigurationseigenschaft allow-introspection true im runtime.graphql Konfigurationsabschnitt festlegen. Zum Beispiel:

"runtime": {
    "...": "...",
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "..."
}

GraphQL-Endpunkt: "Der Mutationsvorgang <operation_name> war erfolgreich, der aktuelle Benutzer ist jedoch nicht berechtigt, die Antwort aufgrund fehlender Leseberechtigungen anzuzeigen"

Damit ein GraphQL-Mutationsvorgang eine gültige Antwort erhält, sollten Leseberechtigungen zusätzlich zum jeweiligen Mutationsvorgangstyp konfiguriert werden – Erstellen, Aktualisieren und Löschen. Wie der Fehler vermuten lässt, war der Mutationsvorgang (Erstellen/Aktualisieren/Löschen) auf der Datenbankebene erfolgreich, aber aufgrund der fehlenden Leseberechtigung hat der Daten-API-Generator eine Fehlermeldung zurückgegeben. Stellen Sie daher sicher, dass Sie Leseberechtigungen entweder in der Rolle "Anonym" oder in der Rolle konfigurieren, mit der Sie den Mutationsvorgang ausführen möchten.

Allgemeiner Fehler: HTTP 500-Fehler, der von Anforderungen zurückgegeben wird

HTTP 500-Fehler deuten darauf hin, dass der Daten-API-Generator nicht ordnungsgemäß in der Back-End-Datenbank ausgeführt werden kann. Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Der Daten-API-Generator kann weiterhin eine Verbindung mit der konfigurierten Datenbank herstellen.
  • Die datenbankobjekte, die vom Daten-API-Generator verwendet werden, sind weiterhin verfügbar und zugänglich.

Um dem Daten-API-Generator die Rückgabe bestimmter Datenbankfehler in Antworten zu ermöglichen, legen Sie die runtime.host.mode Konfigurationseigenschaft auf :development

"runtime": {
    [...]
    "host": {
        "mode": "development",
        [...]
    }
}

Standardmäßig wird der Daten-API-Generator mit runtime.host.mode festgelegter Eigenschaft productionausgeführt. Im production Modus gibt der Daten-API-Generator keine detaillierten Fehler in der Antwortnutzlast zurück.

In beiden development Modi production schreibt der Daten-API-Generator detaillierte Fehler in die Konsole, um bei der Problembehandlung zu helfen.

Allgemeine Fehler aufgrund nicht authentifizierter und nicht autorisierter Anforderungen

HTTP 401 "Nicht autorisiert" Fehler

HTTP 401-Fehler treten auf, wenn der Endpunkt und die Entität, auf die zugegriffen wird, eine Authentifizierung erfordern und der Anforderer keine gültigen Authentifizierungsmetadaten in ihrer Anforderung bereitstellt.

Wenn Sie den Daten-API-Generator für die Verwendung der Microsoft Entra ID-Authentifizierung konfigurieren, führen Ihre Anforderungen zu HTTP 401-Fehlern, wenn das bereitgestellte Bearertoken (Zugriffstoken) ungültig ist. Ein Zugriffstoken kann aus vielen Gründen ungültig sein. Hier sind einige davon:

  • Das Zugriffstoken ist abgelaufen.
  • Das Zugriffstoken ist nicht für die API des Daten-API-Generators (falsche Zugriffstokengruppe) vorgesehen.
  • Das Zugriffstoken wird nicht von der erwarteten Autorität (ungültiger Zugriffstokenherausgeber) erstellt.

Um diesen Fehler zu beheben, stellen Sie sicher, dass sie die folgenden Bedingungen erfüllen:

  • Sie generieren ein Zugriffstoken mithilfe des issuer im authentication Abschnitt der Laufzeitkonfiguration definierten Werts.

  • Ihr Zugriffstoken wird für den audience im authentication Abschnitt der Laufzeitkonfiguration definierten Wert generiert.

Hier sehen Sie eine Beispielkonfiguration:

"authentication": {
    "provider": "AzureAD",
    "jwt": {
        "issuer": "https://login.microsoftonline.com/24c24d79-9790-4a32-bbb4-a5a5c3ffedd5/v2.0/",
        "audience": "b455fa3c-15fa-4864-8bcd-88fd83d686f3"
    }
}

Sie müssen ein gültiges Token für die definierte Zielgruppe generieren. Wenn Sie die Azure CLI verwenden, können Sie ein Zugriffstoken abrufen, indem Sie die Zielgruppe im resource Parameter angeben:

az account get-access-token --resource "b455fa3c-15fa-4864-8bcd-88fd83d686f3"

HTTP 403 "Verboten"-Fehler

Wenn Sie eine authentifizierte Anforderung mit static Web-Apps Integration oder Microsoft Entra ID senden, erhalten Sie möglicherweise einen HTTP 403 "Verboten"-Fehler. Dieser Fehler gibt an, dass Sie versuchen, eine Rolle zu verwenden, die in der Konfigurationsdatei nicht vorhanden ist.

Dieser Fehler tritt unter den folgenden Umständen auf:

  • Sie geben X-MS-API-ROLE keinen HTTP-Header an, der einen Rollennamen angibt.

    Da authentifizierte Anforderungen standardmäßig im Kontext der Systemrolle authenticated ausgeführt werden, gilt dieses Szenario nur, wenn Sie eine Nicht-Systemrolle verwenden (weder authenticated noch anonymous).

  • Die Rolle, die X-MS-API-ROLE Sie im Header definieren, ist in der Laufzeitkonfigurationsdatei des Daten-API-Generators nicht konfiguriert.

  • Die rolle, die X-MS-API-ROLE Sie im Header definieren, stimmt nicht mit der Rolle in Ihrem Zugriffstoken überein.

Beispielsweise wird in der folgenden Laufzeitkonfigurationsdatei die Rolle role1 definiert, sodass Sie einen X-MS-API-ROLE HTTP-Header mit dem Wert role1angeben müssen.

Notiz

Beim Abgleich von Rollennamen wird die Groß- und Kleinschreibung beachtet.

"Todo": {
    "role": "role1",
    "actions": [ "*" ]
}

References

Nächster Schritt

Wenn Ihr Problem nicht behoben ist, geben Sie Feedback ein, oder melden Sie es in den Diskussionen des Daten-API-Generators.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.