API-Zugriffsrichtlinie

Die API-Zugriffsrichtlinie steuert den Zugriff auf API-Ressourcen. Manchmal ist es erforderlich, dass ein Titel bestimmte APIs vom Spielclient zulässt oder verweigert, aus Anti-Cheat- oder anderen Sicherheitsgründen. Sie können den Zugriff mithilfe von Richtlinienanweisungen steuern, um eine Reihe von Zugriffsregeln anzugeben, die in bestimmten Situationen angewendet werden.

In diesem Thema wird die Verwendung von API-Berechtigungsrichtlinien zum Erstellen der entsprechenden Regeln erläutert.

Wichtig

In diesem Leitfaden werden erweiterte Techniken erläutert. Bei falscher Anwendung ist es möglich, den Clientzugriff auf Ihren Titel mithilfe dieses Features vollständig zu deaktivieren.

Richtliniensteuerung und -struktur

Titel verwenden die PlayFab Admin API-Aufrufe, um die Zugriffsrichtlinien abzurufen und zu aktualisieren. Die beiden spezifischen Aufrufe, die Sie zum Festlegen der API-Zugriffsrichtlinie verwenden, sind GetPolicy und UpdatePolicy. Weitere Informationen zu den Admin API-Aufrufen finden Sie unter PlayFab-API-Referenz.

Um die Admin-API verwenden zu können, müssen Sie den geheimen Entwicklerschlüssel angeben, der Ihrem Titel zugeordnet ist. Der Entwicklerschlüssel wird verwendet, um Ihren Titel für Admin API-Aufrufe zu autorisieren. Informationen zum Abrufen Ihres geheimen Schlüssels finden Sie unter Verwaltung geheimer Schlüssel.

Jede Richtlinie enthält eine Liste von Anweisungen, die als Regeln für eine oder mehrere PlayFab-Ressourcen fungieren. PlayFab definiert einen Standardsatz von Richtlinienanweisungen, der alle Richtlinien zulässt. Wenn Sie diese Richtlinienanweisung löschen, ohne sie zu ersetzen, kann Ihr Titel die Client-APIs nicht aufrufen.

Die Standardmäßigen PlayFab-Richtlinienanweisungen:

    "Statements": [
        {
            "Resource": "pfrn:api--*",
            "Action": "*",
            "Effect": "Allow",
            "Principal": "*",
            "Comment": "The default allow all policy"
        }
    ]

Jeder Satz von Berechtigungsanweisungen besteht aus den folgenden Elementen, die in Authentifizierung – Updaterichtlinie definiert sind:

• Ressource: Eine Zeichenfolge, die eine oder mehrere PlayFab-Ressourcen eindeutig identifiziert.

  Verwenden Sie die unten gezeigte Konvention, um die API-Ressource zu beschreiben.

  pfrn:api--/API-GROUP/API-CALL

  Geben Sie die Client-API als an API-GROUP: Client, Serveroder Admin.

  Ersetzen Sie durch API-CALL einen API-Namen wie ConfirmPurchase, LoginWithTwitchoder ReportPlayer.

  Eine Ressourcenzeichenfolge unterstützt Wildcards. Die folgende Ressourcenzeichenfolge stimmt mit jeder Ressource überein.

  pfrn:api--*

• Aktion: Eine Zeichenfolge, die einen Vorgang beschreibt, der für die Ressource ausgeführt werden soll. Verwenden Sie * , um einen beliebigen Vorgang abzugleichen.

• Effect: Eine Zeichenfolge, die eine Regeldefinition angibt. Verwenden Sie Allow oder Deny , um Vorgänge für die Ressource zuzulassen oder zu verweigern.

• Prinzipal: Eine Zeichenfolge, die die Klasse des Benutzers eindeutig identifiziert. Verwenden Sie * , um einen beliebigen Benutzer abzugleichen.

• Kommentar: Eine benutzerdefinierte Zeichenfolge, die weitere Informationen zur Richtlinienanweisungen enthält.

• ApiConditions: Ein optionales Objekt , das erweiterte Regelbedingungen definiert, z. B. Verschlüsselung und signierte Header.

Sie können strenge Sicherheitsregeln für Ihre Anwendung festlegen, indem Sie Ihre Richtlinie so ändern, dass detailliertere Berechtigungsanweisungen verwendet werden, die nur den Zugriff durch die APIs erlauben, die Sie in Ihrer Anwendung verwenden.

Das folgende Beispiel zeigt, wie Sie den DeleteCharacterFromUser Aufruf einschränken:

    {
        "Resource": "pfrn:api--/Server/DeleteCharacterFromUser",
        "Action": "",
        "Effect": "Deny",
        "Principal": "",
        "Comment": "Disable server character delete"
    }

Beispiel für API-Zugriffsrichtlinie

Das folgende Codebeispiel zeigt grundlegende Vorgänge mit Richtlinien. Der Code führt die folgenden Aktionen aus:

• Ruft die vorhandene Richtlinie ab und protokolliert sie.
• Updates die Richtlinie.
• Ruft die vorhandene Richtlinie ab und protokolliert sie erneut.

public void Start() {
    PlayFabSettings.staticSettings.DeveloperSecretKey = "<insert key here>";
    PlayFabSettings.TitleId = "< insert title id here >";
    FetchApiPolicy(UpdateApiPolicy);
}

private void FetchApiPolicy(Action nextAction = null) {
    PlayFabAdminAPI.GetPolicy(new GetPolicyRequest() {
        PolicyName = "ApiPolicy"
    }, result => {
        Debug.Log(result.PolicyName);
        foreach (var statement in result.Statements)
        {
            Debug.Log("Action: "+ statement.Action);
            Debug.Log("Comment: "+ statement.Comment);
            if(statement.ApiConditions != null)
                Debug.Log("ApiCondition.HashSignatureOrEncryption: "+ statement.ApiConditions.HasSignatureOrEncryption);
            Debug.Log("Effect: "+ statement.Effect);
            Debug.Log("Principal: "+statement.Principal);
            Debug.Log("Resource: "+ statement.Resource);
        }

        if (nextAction != null) nextAction();

    },error=>Debug.LogError(error.GenerateErrorReport()));
}

private void UpdateApiPolicy() {
    PlayFabAdminAPI.UpdatePolicy(new UpdatePolicyRequest() {
        PolicyName = "ApiPolicy",
        OverwritePolicy = false, // Append to existing policy. Set to True, to overwrite.
        Statements = new List<PermissionStatement>() {
            new PermissionStatement() {
                Action = "*", // Statement effects Execute action
                ApiConditions = new ApiCondition() {
                    HasSignatureOrEncryption = Conditionals.False // Require no RSA encrypted payload or signed headers
                },
                Comment = "Do not allow clients to confirm purchase",
                Resource = "pfrn:api--/Client/ConfirmPurchase", // Resource name
                Effect = EffectType.Deny, // Do not allow,
                Principal = "*"
            }
        }
    }, result => {
        FetchApiPolicy();
    }, error => Debug.LogError(error.GenerateErrorReport()));
}

Die folgende Abbildung zeigt ein Beispiel für die Ausgabe, nachdem der Code zum ersten Mal ausgeführt wurde. Wie gezeigt, besteht die Richtlinie aus mehreren Berechtigungsanweisungen.