onebot
onebot copied to clipboard
botuniverse
支持使用 URL query 参数传递鉴权 token
摘要
在 Authorization 头之外，允许通过 /?access_token=xxx 来传递 access_token。
动机
部分场景下，应用端或 OneBot 实现无法操作 HTTP 请求头，例如：
- 浏览器和 Deno 发起 WebSocket 连接时
- IFTTT Maker Webhooks
具体描述
通信方式 - HTTP、正向 WebSocket
“鉴权”部分，实现应优先检查 Authorization 头，如果存在，则依照原来的标准鉴权，如果不存在，则尝试获取 access_token URL query 参数，以此鉴权。
通信方式 - HTTP Webhook
“请求头”部分，若无法操作请求头，实现可以通过 access_token URL query 参数来传递 token，应用端应优先检查 Authorization 头，如果存在，则依照原来的标准鉴权，如果不存在，则尝试获取 access_token URL query 参数，以此鉴权。
反向 WebSocket 文档会指向此处，故不用修改。
局限
无。
替代方案
无。
目前一个问题是如果 OneBot 实现端跑在 Deno 或浏览器中，发起反向 WS 连接也无法设置 header，所以需要允许实现端也可以通过 access_token 传递 token。
另外还有 X-OneBot-Version X-Impl X-Platform X-Self-ID 几个 header，可以使用 WebSocket 的 Sec-WebSocket-Protocol 头来传递，也就是 #164 的建议。
是不是关于请求头解析替代应该规定一个转换表和优先级？下面是我的假想方案，只作为补充。
方案一，使用 GET 传参
使用 GET 参数传参
对于部分不支持自定义 Header 的 OneBot 实现或逻辑端中，可以使用 GET 参数来替代 Header 字段的内容，但无论对于哪一方而言，都必须对两者支持解析。
| Header 参数名 | GET 参数名 | 说明 |
|---|---|---|
Authorization |
access_token |
Authorization 头以 Bearer 开头，转换为 GET 传参只需传入后面的 token 字段 |
X-OneBot-Version |
onebot_version |
|
X-Impl |
impl |
|
X-Platform |
platform |
|
X-Self-ID |
self_id |
传入优先级
当 GET 参数和 Header 参数同时传入时，实现和逻辑端应以 GET 参数优先。
方案二，采用 Sec-WebSocket-Protocol
使用合并 Header 传入
对于部分不支持自定义 Header 的 OneBot 实现或逻辑端，例如浏览器（以目前的 Chrome 102 为准）仅支持自定义一种 Header：Sec-WebSocket-Protocol，可以采用该 Header 进行传递和声明，具体规定如下：
- 该头传入的内容为 JSON，为 k-v 类型，key 对应要传入的头名称，例如
X-OneBot-Version - 对 JSON 对象采用 Base64 处理，传入该 Header
- 如果原 Header 与该 Header 均存在时，该 Header 将被忽略。但当必需的 Header 缺失时，如果该 Header 可解析 Base64 和 JSON，则从解析后的 JSON 对象中取出
