feat(m5b): pallas_protocol 改名为 pb_protocol#218
Merged
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - 我发现了 2 个安全问题、5 个其他问题，并留下了一些整体性的反馈：
安全问题：
- 检测到不安全的 WebSocket。所有 WebSocket 连接都应使用加密的 WebSocket Secure（wss）。(link)
- 检测到不安全的 WebSocket。所有 WebSocket 连接都应使用加密的 WebSocket Secure（wss）。(link)
总体评论：
- 在
pb_protocol_data_dir中，一次性迁移直接使用legacy.rename(new_root)，没有做错误处理；建议用 try/except 包裹，并在失败时回退到更安全的策略（例如 copy + remove），以避免在跨文件系统移动或启动时权限问题导致失败。 - 迁移保护开关
_migrated仅在进程内生效；如果有多个进程并发启动，它们可能会在pallas_protocol→pb_protocol重命名时发生竞争——如果这是一个可能的场景，你可能需要增加文件系统层面的保护（例如检测新目录是否存在，或者使用锁文件），从而让该操作在多进程下也足够健壮。
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `pb_protocol_data_dir`, the one-time migration uses `legacy.rename(new_root)` without error handling; consider wrapping this in a try/except and falling back to a safer strategy (e.g., copy + remove) to avoid failures on cross-filesystem moves or permission issues during startup.
- The migration guard `_migrated` is process-local; if multiple processes start concurrently they may race on the `pallas_protocol` → `pb_protocol` rename—if this is a concern, you may want to add a filesystem-level guard (e.g., presence of the new dir or a lock file) to make the operation robust across processes.
## Individual Comments
### Comment 1
<location path="src/plugins/pb_protocol/data_dir.py" line_range="17-25" />
<code_context>
+_migrated = False
+
+
+def pb_protocol_data_dir(*, create: bool = True) -> Path:
+ global _migrated
+ if create and not _migrated:
+ legacy = plugin_data_dir(_LEGACY_PLUGIN, create=False)
+ new_root = plugin_data_dir(_CURRENT_PLUGIN, create=False)
+ if legacy.is_dir() and not new_root.exists():
+ legacy.rename(new_root)
+ _migrated = True
+ return plugin_data_dir(_CURRENT_PLUGIN, create=create)
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard the legacy→current data dir rename against cross-process races
This migration is only guarded by the process-local `_migrated` flag. With multiple concurrent processes, more than one can see `legacy.is_dir()` and `not new_root.exists()` as true and attempt `legacy.rename(new_root)`, causing a `FileNotFoundError`/`OSError` and failing startup.
Please make the rename resilient to this race, e.g. by wrapping it in `try`/`except` for `FileNotFoundError`/`OSError` (only treating unexpected errors as fatal), or by re-checking `legacy.exists()` in a small try-block so concurrent migrations don’t crash the process.
</issue_to_address>
### Comment 2
<location path="src/platform/shard/data_sync.py" line_range="18-19" />
<code_context>
_REGISTRY_FILE = "registry.json"
+def _accounts_data_dir():
+ return pb_protocol_data_dir(create=False)
+
+
</code_context>
<issue_to_address>
**question (bug_risk):** Consider whether shard data sync should also trigger protocol data dir migration
Because `_accounts_data_dir()` passes `create=False` to `pb_protocol_data_dir`, it never runs the migration logic there (which only executes when `create=True`). As a result, `_current_mtuples()` will ignore an existing legacy `pallas_protocol` accounts dir until some other code path calls `pb_protocol_data_dir(create=True)`. If shard data sync must work before the pb_protocol plugin is initialized (or in setups that only run registry syncing), consider having `_accounts_data_dir()` also trigger migration (e.g., by calling `pb_protocol_data_dir(create=True)` or via a helper that performs migration without creating a new dir).
</issue_to_address>
### Comment 3
<location path="src/console/webui/protocol_accounts.py" line_range="15" />
<code_context>
def protocol_account_display_names() -> dict[str, str]:
global _cached_mtime, _cached_names
- path = plugin_data_dir("pallas_protocol") / "accounts.json"
+ path = pb_protocol_data_dir(create=False) / "accounts.json"
if not path.is_file():
return {}
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Protocol accounts view might not see legacy pallas_protocol data without a migration trigger
Because this uses `pb_protocol_data_dir(create=False)`, the migration from `pallas_protocol` to `pb_protocol` won’t run here. If the web UI is hit before anything calls `pb_protocol_data_dir(create=True)`, the account list can appear empty even though `accounts.json` still exists in the legacy folder.
To avoid that, either call `pb_protocol_data_dir(create=True)` here so migration runs, or factor out a helper that performs a “migrate-if-legacy-exists” step (without creating a new dir when neither exists) and use that instead. This keeps behavior consistent regardless of initialization order.
</issue_to_address>
### Comment 4
<location path="tests/common/web/test_log_facets.py" line_range="11" />
<code_context>
("pallas_webui", "hello", True, False),
("other", "[pallas-webui] x", True, False),
- ("pallas_protocol", "y", False, True),
+ ("pb_protocol", "y", False, True),
("x", "[pallas-protocol] z", False, True),
("nonebot", "plain", False, False),
</code_context>
<issue_to_address>
**suggestion (testing):** Also test that legacy pallas_protocol logger name still maps to the protocol facet
This parametrized test now only checks the new `pb_protocol` logger name, even though `nonebot_log_record_matches_http_facet` still treats both `pb_protocol` and `pallas_protocol` as protocol logs. Please add a parameter for the legacy name as well (e.g. `("pallas_protocol", "y", False, True)`) to verify the backward-compatibility behavior remains covered.
</issue_to_address>
### Comment 5
<location path="docs/FAQ.md" line_range="172" />
<code_context>
+A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**suggestion (typo):** Link text still uses `pallas_protocol` while pointing to `pb_protocol` docs.
The target path is correct, but the link label still says ``[`pallas_protocol` 插件说明]``. Please rename the inline code/link text to `pb_protocol` for consistency with the updated plugin name, unless you intend to keep the old name here for a specific reason.
</issue_to_address>
### Comment 6
<location path="docs/FAQ.md" line_range="172" />
<code_context>
A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
*Source: opengrep*
</issue_to_address>
### Comment 7
<location path="docs/FAQ.md" line_range="172" />
<code_context>
A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
*Source: opengrep*
</issue_to_address>帮我变得更有用！请在每条评论上点 👍 或 👎，我会根据这些反馈改进后续的 review。
Original comment in English
Hey - I've found 2 security issues, 5 other issues, and left some high level feedback:
Security issues:
- Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. (link)
- Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. (link)
General comments:
- In
pb_protocol_data_dir, the one-time migration useslegacy.rename(new_root)without error handling; consider wrapping this in a try/except and falling back to a safer strategy (e.g., copy + remove) to avoid failures on cross-filesystem moves or permission issues during startup. - The migration guard
_migratedis process-local; if multiple processes start concurrently they may race on thepallas_protocol→pb_protocolrename—if this is a concern, you may want to add a filesystem-level guard (e.g., presence of the new dir or a lock file) to make the operation robust across processes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `pb_protocol_data_dir`, the one-time migration uses `legacy.rename(new_root)` without error handling; consider wrapping this in a try/except and falling back to a safer strategy (e.g., copy + remove) to avoid failures on cross-filesystem moves or permission issues during startup.
- The migration guard `_migrated` is process-local; if multiple processes start concurrently they may race on the `pallas_protocol` → `pb_protocol` rename—if this is a concern, you may want to add a filesystem-level guard (e.g., presence of the new dir or a lock file) to make the operation robust across processes.
## Individual Comments
### Comment 1
<location path="src/plugins/pb_protocol/data_dir.py" line_range="17-25" />
<code_context>
+_migrated = False
+
+
+def pb_protocol_data_dir(*, create: bool = True) -> Path:
+ global _migrated
+ if create and not _migrated:
+ legacy = plugin_data_dir(_LEGACY_PLUGIN, create=False)
+ new_root = plugin_data_dir(_CURRENT_PLUGIN, create=False)
+ if legacy.is_dir() and not new_root.exists():
+ legacy.rename(new_root)
+ _migrated = True
+ return plugin_data_dir(_CURRENT_PLUGIN, create=create)
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard the legacy→current data dir rename against cross-process races
This migration is only guarded by the process-local `_migrated` flag. With multiple concurrent processes, more than one can see `legacy.is_dir()` and `not new_root.exists()` as true and attempt `legacy.rename(new_root)`, causing a `FileNotFoundError`/`OSError` and failing startup.
Please make the rename resilient to this race, e.g. by wrapping it in `try`/`except` for `FileNotFoundError`/`OSError` (only treating unexpected errors as fatal), or by re-checking `legacy.exists()` in a small try-block so concurrent migrations don’t crash the process.
</issue_to_address>
### Comment 2
<location path="src/platform/shard/data_sync.py" line_range="18-19" />
<code_context>
_REGISTRY_FILE = "registry.json"
+def _accounts_data_dir():
+ return pb_protocol_data_dir(create=False)
+
+
</code_context>
<issue_to_address>
**question (bug_risk):** Consider whether shard data sync should also trigger protocol data dir migration
Because `_accounts_data_dir()` passes `create=False` to `pb_protocol_data_dir`, it never runs the migration logic there (which only executes when `create=True`). As a result, `_current_mtuples()` will ignore an existing legacy `pallas_protocol` accounts dir until some other code path calls `pb_protocol_data_dir(create=True)`. If shard data sync must work before the pb_protocol plugin is initialized (or in setups that only run registry syncing), consider having `_accounts_data_dir()` also trigger migration (e.g., by calling `pb_protocol_data_dir(create=True)` or via a helper that performs migration without creating a new dir).
</issue_to_address>
### Comment 3
<location path="src/console/webui/protocol_accounts.py" line_range="15" />
<code_context>
def protocol_account_display_names() -> dict[str, str]:
global _cached_mtime, _cached_names
- path = plugin_data_dir("pallas_protocol") / "accounts.json"
+ path = pb_protocol_data_dir(create=False) / "accounts.json"
if not path.is_file():
return {}
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Protocol accounts view might not see legacy pallas_protocol data without a migration trigger
Because this uses `pb_protocol_data_dir(create=False)`, the migration from `pallas_protocol` to `pb_protocol` won’t run here. If the web UI is hit before anything calls `pb_protocol_data_dir(create=True)`, the account list can appear empty even though `accounts.json` still exists in the legacy folder.
To avoid that, either call `pb_protocol_data_dir(create=True)` here so migration runs, or factor out a helper that performs a “migrate-if-legacy-exists” step (without creating a new dir when neither exists) and use that instead. This keeps behavior consistent regardless of initialization order.
</issue_to_address>
### Comment 4
<location path="tests/common/web/test_log_facets.py" line_range="11" />
<code_context>
("pallas_webui", "hello", True, False),
("other", "[pallas-webui] x", True, False),
- ("pallas_protocol", "y", False, True),
+ ("pb_protocol", "y", False, True),
("x", "[pallas-protocol] z", False, True),
("nonebot", "plain", False, False),
</code_context>
<issue_to_address>
**suggestion (testing):** Also test that legacy pallas_protocol logger name still maps to the protocol facet
This parametrized test now only checks the new `pb_protocol` logger name, even though `nonebot_log_record_matches_http_facet` still treats both `pb_protocol` and `pallas_protocol` as protocol logs. Please add a parameter for the legacy name as well (e.g. `("pallas_protocol", "y", False, True)`) to verify the backward-compatibility behavior remains covered.
</issue_to_address>
### Comment 5
<location path="docs/FAQ.md" line_range="172" />
<code_context>
+A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**suggestion (typo):** Link text still uses `pallas_protocol` while pointing to `pb_protocol` docs.
The target path is correct, but the link label still says ``[`pallas_protocol` 插件说明]``. Please rename the inline code/link text to `pb_protocol` for consistency with the updated plugin name, unless you intend to keep the old name here for a specific reason.
</issue_to_address>
### Comment 6
<location path="docs/FAQ.md" line_range="172" />
<code_context>
A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
*Source: opengrep*
</issue_to_address>
### Comment 7
<location path="docs/FAQ.md" line_range="172" />
<code_context>
A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
*Source: opengrep*
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| ("pallas_webui", "hello", True, False), | ||
| ("other", "[pallas-webui] x", True, False), | ||
| ("pallas_protocol", "y", False, True), | ||
| ("pb_protocol", "y", False, True), |
Contributor
There was a problem hiding this comment.
suggestion (testing): 建议同时测试旧版 pallas_protocol 日志名仍能映射到 protocol 维度
当前这个参数化测试只验证了新的 pb_protocol 日志记录器名称，但 nonebot_log_record_matches_http_facet 实际上仍会将 pb_protocol 和 pallas_protocol 都视为 protocol 日志。请增加一个旧名称的参数（例如 ("pallas_protocol", "y", False, True)），以验证向后兼容的行为仍被测试覆盖。
Original comment in English
suggestion (testing): Also test that legacy pallas_protocol logger name still maps to the protocol facet
This parametrized test now only checks the new pb_protocol logger name, even though nonebot_log_record_matches_http_facet still treats both pb_protocol and pallas_protocol as protocol logs. Please add a parameter for the legacy name as well (e.g. ("pallas_protocol", "y", False, True)) to verify the backward-compatibility behavior remains covered.
| ### Q: 协议端管理里反向 WebSocket 要不要写成「主机为 `pallasbot`」？和 Compose 的 `pallasbot` 是什么关系？ | ||
|
|
||
| A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pallas_protocol/README.md) 中「Docker 与反向 WebSocket」一节。 | ||
| A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。 |
Contributor
There was a problem hiding this comment.
security (javascript.lang.security.detect-insecure-websocket): 检测到不安全的 WebSocket。所有 WebSocket 连接都应使用加密的 WebSocket Secure（wss）。
Source: opengrep
Original comment in English
security (javascript.lang.security.detect-insecure-websocket): Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
Source: opengrep
| ### Q: 协议端管理里反向 WebSocket 要不要写成「主机为 `pallasbot`」？和 Compose 的 `pallasbot` 是什么关系？ | ||
|
|
||
| A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pallas_protocol/README.md) 中「Docker 与反向 WebSocket」一节。 | ||
| A: **`pallasbot` 只是 Compose 服务名**，DNS 只在**同一 Compose 网络里的容器**之间有效。协议端在 **Linux Docker 模式**下用 `docker run` 起的 NapCat **默认不在**该网络里；若把客户端地址写成 **`ws://pallasbot:<PORT>/onebot/v11/ws`**（明文 WebSocket、主机填服务名），在默认桥接场景下**往往连不上**。插件会把 **主机** 改成解析后的 **`PALLAS_PROTOCOL_DOCKER_ONEBOT_HOST`**（留空时 Linux **`bridge`** 多为**默认网关 IP** 或 **`172.17.0.1`**；**`host` 网络为 `127.0.0.1`**）再写入 **`onebot*.json`**，**不会**自动替你填 `pallasbot`。一般不必为此去「取消」Compose 自定义网络；只有当你**自行**把 NapCat 做成与 Bot **同一 Compose 网络**的 service 时，才适合继续用 **`ws://pallasbot:<PORT>/onebot/v11/ws`** 这类内网写法。详见 [Docker 部署](DockerDeployment.md) 与 [`pallas_protocol` 插件说明](plugins/pb_protocol/README.md) 中「Docker 与反向 WebSocket」一节。 |
Contributor
There was a problem hiding this comment.
security (javascript.lang.security.detect-insecure-websocket): 检测到不安全的 WebSocket。所有 WebSocket 连接都应使用加密的 WebSocket Secure（wss）。
Source: opengrep
Original comment in English
security (javascript.lang.security.detect-insecure-websocket): Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.
Source: opengrep
- 抽取 migrate_*_if_needed，create=False 也会触发迁移 - rename 捕获并发 FileNotFoundError/OSError - 补 legacy pallas_protocol 日志 facet 测试与 FAQ 链接文案
TogetsuDo
added a commit
that referenced
this pull request
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pallas_protocol→pb_protocol（目录、测试、文档、matrix、help 别名）plugin_package_aliases保留pallas_protocol→pb_protocol兼容映射data/pallas_protocol/启动时一次性迁移至data/pb_protocol/PALLAS_PROTOCOL_*保持不变Test plan
uv run ruff check src/pytest tests/plugins/pb_protocol/26 passedSummary by Sourcery
将核心 QQ 协议管理插件在代码、测试和文档中从
pallas_protocol重命名为pb_protocol，同时在配置和插件别名层面保持向后兼容。Enhancements:
pb_protocol_data_dir辅助函数来访问协议账号数据目录，并在首次使用时迁移现有的pallas_protocol数据。pb_protocol识别为主要的协议插件标识符。pb_protocol路径读取协议账号数据，而不是依赖硬编码的plugin_data_dir查找。Documentation:
pb_protocol插件及其文档路径。Tests:
pb_protocol，并扩展插件矩阵测试，以覆盖新旧名称在别名处理和打包加载行为上的测试。Chores:
pb_protocol纳入其中，并保留pallas_protocol作为兼容性的遗留别名。pb_protocol标识符和路径。Original summary in English
Summary by Sourcery
Rename the core QQ protocol management plugin from pallas_protocol to pb_protocol across code, tests, and docs while preserving backward compatibility for configuration and plugin aliases.
Enhancements:
Documentation:
Tests:
Chores: