跳到主要内容

架构考虑

客户端->服务器 vs. 服务器->服务器​

所有 k-ID API 调用都需要在 Authorization 头中包含有效的 k-ID API 令牌或 API 密钥本身。k-ID API 令牌对于允许 k-ID 集成到较小工作室的游戏中非常有用，这些工作室可能无法访问可定制的游戏后端，并且会直接从游戏客户端调用 k-ID API。例如， k-ID Unreal 示例 使用 API 令牌和客户端的直接 k-ID 调用，使开发人员可以轻松地在本地运行。

另一方面，大多数 k-ID 的部署将通过工作室控制的游戏服务器进行。这是强烈推荐的，因为它可以保护 API 密钥不被滥用。在这种情况下，不需要 API 令牌，并且可以将 API 密钥用作所有 API 调用的授权头。

获取 k-ID 令牌​

客户端令牌是通过 /auth/issue-token API 创建的。 /auth/issue-token API 本身需要 Authorization 头，但需要游戏的 k-ID API 密钥。提醒：不要在游戏客户端中分发包含API密钥的版本。该密钥必须存储在服务器的安全位置，并且至少/auth/issue-token调用必须由服务器而不是客户端向k-ID发起。

在 Unreal C++ 中从客户端获取客户端令牌
void UKidWorkflow::Initialize(TFunction<void(bool)> Callback)
{
   FString payload = TEXT("{ "clientId": "") + ClientId + TEXT(""}");


   HttpRequestHelper::PostRequestWithAuth(BaseUrl + 
              TEXT("/auth/issue-token"), payload, ApiKey,
              [this, Callback](FHttpResponsePtr Response, bool bWasSuccessful)
   {
       if (bWasSuccessful && Response.IsValid())
       {
           TSharedPtr<FJsonObject> JsonResponse;
           TSharedRef<TJsonReader<>> Reader = 
                TJsonReaderFactory<>::Create(Response->GetContentAsString());
           if (FJsonSerializer::Deserialize(Reader, JsonResponse))
           {
               AuthToken = JsonResponse->GetStringField(TEXT("accessToken"));
               UE_LOG(LogTemp, Log, TEXT("AuthToken generated: %s"), *AuthToken);
           }
       }
       Callback(bWasSuccessful);
   });
}

游戏可靠性和缓存​

k-ID API 高度可用。但建议游戏在调用服务器到服务器时为 k-ID API 实现常见的可靠性和容错模式（例如，断路器）。由于所有玩家都需要一个 Session，因此游戏应实施一种方法，以确保在 k-ID 服务出现问题的情况下，新玩家和现有玩家不会被阻止。

缓存的会话​

Session 应该缓存到本地或云存储中，并且可以与玩家的帐户相关联。虽然建议游戏在每次重新启动时从 /session/get API 刷新会话，但这不是明确要求的。如果 k-ID API 出现问题，刷新可以推迟到稍后进行。缓存的会话可以在问题解决期间用于管理权限，而无需连接到 k-ID API。

默认会话​

对于新玩家，可以在游戏服务器中缓存每个管辖区的默认权限，以便在 k-ID 服务出现问题时，可以为新玩家提供合理的默认值。/age-gate/get-default-permissions API 返回每个管辖区的默认权限。默认权限包括为特定游戏配置的所有设置，并且可以作为回退，因为它们不由父母管理。缓存的默认 k-ID 权限也可以通过其他渠道（例如远程配置）传送到游戏中。