当 AWS Websocket Api Gateway 尝试通过 Cloudfront 提供服务时出现 403 Forbidden

我使用 AWS 的 websocket API 网关创建了一个 Websocket API。创建 api 后，我得到了像这样的端点

wss://x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com/dev

我可以直接使用它并调用$connectlambda 没有任何问题

现在我希望它通过云前端提供服务。

我已经有一个具有备用域名的发行版，例如app.blablabla.cloud它提供多个 REST API（源类型：API网关）针对不同的服务。我也想对 websocket API 做同样的事情

我为发行版创建了一个新的自定义来源

• 原始域 -x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com
• 协议 -仅 HTTPS
• HTTPS 端口 - 443
• 最低来源 SSL 协议 - TLS v1
• 原点路径 -留空
• 其余配置 - 默认

之后我创建了一个行为并附加了这个原点

• 路径模式 -/dev/my-socket/*
• 自动压缩对象 - 是
• 观众 -仅 HTTPS
• 允许的 HTTP 方法 - GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE
• 限制查看者访问 - 否
• 缓存密钥和源请求 - 缓存策略和源请求策略
  缓存策略- 缓存禁用
  原产地请求政策- 创建了一项政策Cookies - All, Query strings - All and Headers - Include the following headers - Sec-WebSocket-Key, Sec-WebSocket-Version, Sec-WebSocket-Protocol, Sec-WebSocket-Accept, Sec-WebSocket-Extensions
• 其余配置 - 默认

现在我尝试使用 url 调用来自邮递员的 wss 初始调用wss://app.blablabla.cloud/dev/my-socket/?param1=1&param2=test

但我明白了Status Code: 403 Forbidden（我期待着一个101 Switching Protocols) 并且请求标头是

Sec-WebSocket-Version: 13
Sec-WebSocket-Key: TVMDG46dqkDM4a7DoM20ZB==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: app.blablabla.cloud

so it looks like cloudfront is hit just can't get it through. the api gateway dashboard also showed something like

我不明白问题出在哪里。非常感谢您的帮助。提前致谢！

EDIT.
后来尝试使用cloudfront功能here https://stackoverflow.com/a/76958086/13583510并认为这是一个更好的方法

问题是 API Gateway’s WebSocket API does not support a path parameter in the connection URL. By design (or say it a design oversight), the connection URL path is fixed to the root path / (stage would be prepended when execute-api endpoint is used).正如本文中提到的中等文章 https://medium.com/@lancers/amazon-api-gateway-websocket-api-cloudfront-function-ab304fd95ac3.

简单来说就是尝试连接wss://x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com/dev/my-socket/?param1=1&param2=test会给出相同的403 禁忌 . Only wss://x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com/dev/?param1=1&param2=test or wss://x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com/dev?param1=1&param2=test works.

即当我尝试连接时wss://app.blablabla.cloud/dev/my-socket/?param1=1&param2=test它必须尝试连接到wss://x5g9h3p2rq.execute-api.eu-central-1.amazonaws.com/dev/my-socket/?param1=1&param2=test

So 方法1

• 在行为改变中路径图案 - /dev并降低优先级，以便其余的dev/stuff/*不受影响。
• 现在我能够做到wss://app.blablabla.cloud/dev?param1=1&param2=test

但这是不可扩展的。如果我们需要另一个套接字 API 该怎么办？我们不能使用相同的/dev对于一切。

这会带来更好的结果方法2

Using Lambda@Edge

• 保持路径模式的行为 -/dev/my-socket/*.
• 创建 Lambda@Edge 并将其与原产地要求
• lambda 很简单，只需更改uri from /dev/my-socket/ to /dev

'use strict';

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  request.uri = request.uri.replace(/\/[^\/]+\/$/, '');
  return callback(null, request);
};

• 现在我能够做到wss://app.blablabla.cloud/dev/my-socket/?param1=1&param2=test它会剥离my-socket并转发到正确的原点。
• 此外，Lambda 仅在连接调用期间被调用。握手完成后，Lambda 不再参与。
• 还注意到与直接使用 API 网关 URL 相比，这种方法有轻微的延迟