标签: google-api-gateway

我正在尝试设置 Google API Gateway 以使用调用者在标头中发送的 API 密钥。
我的 api 配置 yaml 如下所示：

...
securityDefinitions:
  api_key_header:
    type: apiKey
    name: key
    in: header
  api_key_query:
    type: apiKey
    name: key
    in: query
paths:
  /foo-header:
    get:
      summary: Test foo endpoint
      operationId: testGet-header
      x-google-backend:
        address: "<backend address>"
        protocol: h2
        path_translation: APPEND_PATH_TO_ADDRESS
      security:
        - api_key_header: []
      responses:
        204:
          description: A successful response
  /foo-query:
    get:
      summary: Test foo endpoint
      operationId: testGet-header
      x-google-backend:
        address: "<backend address>"
        protocol: h2
        path_translation: APPEND_PATH_TO_ADDRESS
      security:
        - api_key_query: []
      responses:
        204:
          description: A successful …

我在我的 Firebase 应用程序中使用 Google API Gateway 来验证用户是否已登录。在 API Gateway 的文档中，建议使用转发的X-Apigateway-Api-Userinfo标头来检索用户信息：

API Gateway会将X-Apigateway-Api-Userinfo中的认证结果发送给后端API。建议使用此标头代替原始的 Authorization 标头。此标头采用 base64url 编码并包含 JWT 有效负载。

因为它是 base64url 编码的，所以我需要额外的服务器端逻辑来解码它，只是为了获取登录用户的信息（我假设解码的对象对应于 Firebase Auth Admin SDK 的DecodedIdToken）。

另一方面，我发现API Gateway虽然修改了原始Authorization标头，但它首先将其复制到另一个名为X-Forwarded-Authorization. 这意味着我可以做类似的事情：

// authHeaders = 'Bearer ...'
const authHeaders = headers['X-Forwarded-Authorization'];

const token = authHeaders.split(' ')[1]

const decodedToken = await admin.auth().verifyIdToken(token)

我发现这是获取相同信息的更简单（并且有更好记录）的方法。这是一个坏主意吗？我不确定是否还有其他原因X-Apigateway-Api-Userinfo推荐使用标题。

我在 api 网关营销页面上找到了以下代码片段。

因此，我正在为在计算引擎上运行的应用程序设置 API 网关。由于我找不到任何有关如何在 API 引擎上配置计算引擎的文档，因此我使用内部 DNS 创建了以下配置。在此输入链接描述

swagger: "2.0"
info:
  title: API Endpoints
  description: API Endpoints
  version: 1.0.1
schemes:
  - https
produces:
  - application/json
paths:
  /indexes:
    get:
      summary: Return Search Indexes
      operationId: searchIndexes
      x-google-backend:
        address: http://my_internal_dns_for_compute_engine.c.myproject.internal/indexes
        path_translation: APPEND_PATH_TO_ADDRESS
      responses:
        "200":
          description: A successful response
          schema:
            type: string
        "403":
          description: Failed to authenticate

当我使用gcloud部署配置时，出现以下错误

等待为 API [my-api] 创建 API 配置 [my-api-config-v6]...失败。
错误：（gcloud.beta.api-gateway.api-configs.create）等待服务配置创建：后端 URL“http://my_internal_dns_for_compute_engine.c.myproject.internal/indexes”被禁止：无法将请求路由到内部地址。

所以看起来内部 DNS 不受支持（显然）。

我的计算引擎实例只能通过 VPC 网络访问。如何将我的 api 网关连接到 VPC 网络以及如何通过它访问我的计算引擎？

我使用 openapi yaml 文件作为配置应用了 Google 的 API 网关，并收到了新的网关 URL。

我的问题是，如果原始 Cloud Run URL 仍然可以访问，那么网关还有什么意义？

我可以对网关 URL 和 Cloud Run URL 进行完全相同的 Postman 调用，例如https://gateway.api.url.google.com/orders和 https://cloud.run.url.google.com/orders。

我的假设（也是希望）是网关 URL 现在是主 URL，并且对 Cloud Run URL 的任何请求都会路由到 API 网关。任何人都可以阐明这一点吗？