[PR #2820] [CLOSED] fix(security): register extension.manager.supports_csrf_post feature flag (4.2.1) #2804

New issue

Closed

opened 2026-10-28 21:12:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-28 21:12:47 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/ComfyUI-Manager/pull/2820
Author: @ltdrdata
Created: 4/22/2026
Status: ❌ Closed

Base: manager-v4 ← Head: fix/csrf-post-feature-flag

📝 Commits (1)

8eb773e fix(security): register extension.manager.supports_csrf_post feature flag (4.2.1)

📊 Changes

3 files changed (+31 additions, -1 deletions)

View changed files

📝 CHANGELOG.md (+11 -0)
📝 comfyui_manager/__init__.py (+19 -0)
📝 pyproject.toml (+1 -1)

📄 Description

Summary

Register extension.manager.supports_csrf_post = True on ComfyUI core's SERVER_FEATURE_FLAGS at Manager startup, so frontends (ComfyUI_frontend, 3rd-party extensions) can detect CSRF-POST backend capability as a semantic contract via the existing api.getServerFeature(...) mechanism.
Version bump: 4.2 → 4.2.1.
CHANGELOG entry for [4.2.1].
No endpoint or security behavior change — purely a capability-signal patch following up #2818.

Why a new flag (not version parsing)

Version-string parsing (V4.2 vs V4.1) is an implementation-detail check, not a semantic capability contract. Clients that parse the version string couple themselves to Manager's version-format convention (pre-release tags, future version-string format changes, etc.). A server-pushed feature flag is the right abstraction: it declares intent (“this backend supports POST-only state mutation”) independently of the version string.

Coordinated with the ComfyUI_frontend team (cmfront) so they can adopt this flag as the probe for their "NEW_UI vs INCOMPATIBLE" decision. Pre-4.2.1 Manager does not set the flag → frontends treat its absence as incompatible and surface an "upgrade Manager" action to the user.

Mechanism

# comfyui_manager/__init__.py — module load
try:
    from comfy_api import feature_flags as _core_feature_flags
    _mgr_flags = (
        _core_feature_flags.SERVER_FEATURE_FLAGS
        .setdefault("extension", {})
        .setdefault("manager", {})
    )
    _mgr_flags["supports_csrf_post"] = True
except ImportError:
    pass  # older ComfyUI core without comfy_api.feature_flags

.setdefault chain coexists with the pre-existing extension.manager.supports_v4 (hardcoded in core).

Delivery: ComfyUI core pushes SERVER_FEATURE_FLAGS via the WebSocket handshake (see server.py:296) and via GET /api/feature_flags (see server.py:689). Clients use their existing feature-flag infrastructure; no new endpoint on the Manager side.

Test plan

python -m py_compile comfyui_manager/__init__.py → OK
Smoke test (mocked comfy_api.feature_flags with a pre-seeded supports_v4=True): setdefault chain preserves supports_v4 and writes supports_csrf_post=True → final dict exactly {'extension': {'manager': {'supports_v4': True, 'supports_csrf_post': True}}}
ruff check comfyui_manager/ --config ruff.toml → All checks passed
pytest tests/ --ignore=tests/e2e --ignore=tests/playwright --ignore=tests/common/test_git_helper.py -q → 206 passed, 12 skipped (no regression)
grep ^version pyproject.toml → version = "4.2.1"
CI: Code Quality / Ruff / OpenAPI spec / E2E (ubuntu/macOS/Windows)

#2818 — 4.2 baseline CSRF hardening. This PR supplies the capability probe that follow-up frontend work (cmfront PR#11520) will use to decide its UX.
cmfront-team proposed and confirmed the flag name extension.manager.supports_csrf_post.

References

Reported-by: XlabAI Team of Tencent Xuanwu Lab
CVSS: 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/ComfyUI-Manager/pull/2820 **Author:** [@ltdrdata](https://github.com/ltdrdata) **Created:** 4/22/2026 **Status:** ❌ Closed **Base:** `manager-v4` ← **Head:** `fix/csrf-post-feature-flag` --- ### 📝 Commits (1) - [`8eb773e`](https://github.com/Comfy-Org/ComfyUI-Manager/commit/8eb773e39b561fff126bf9137b8a6947b0a0083c) fix(security): register extension.manager.supports_csrf_post feature flag (4.2.1) ### 📊 Changes **3 files changed** (+31 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `CHANGELOG.md` (+11 -0) 📝 `comfyui_manager/__init__.py` (+19 -0) 📝 `pyproject.toml` (+1 -1) </details> ### 📄 Description ## Summary - Register `extension.manager.supports_csrf_post = True` on ComfyUI core's `SERVER_FEATURE_FLAGS` at Manager startup, so frontends (ComfyUI_frontend, 3rd-party extensions) can detect CSRF-POST backend capability **as a semantic contract** via the existing `api.getServerFeature(...)` mechanism. - Version bump: `4.2` → `4.2.1`. - CHANGELOG entry for `[4.2.1]`. - No endpoint or security behavior change — purely a capability-signal patch following up #2818. ### Why a new flag (not version parsing) Version-string parsing (`V4.2` vs `V4.1`) is an implementation-detail check, not a semantic capability contract. Clients that parse the version string couple themselves to Manager's version-format convention (pre-release tags, future version-string format changes, etc.). A server-pushed feature flag is the right abstraction: it declares intent (“this backend supports POST-only state mutation”) independently of the version string. Coordinated with the ComfyUI_frontend team (cmfront) so they can adopt this flag as the probe for their "NEW_UI vs INCOMPATIBLE" decision. Pre-4.2.1 Manager does not set the flag → frontends treat its absence as `incompatible` and surface an "upgrade Manager" action to the user. ## Mechanism ```python # comfyui_manager/__init__.py — module load try: from comfy_api import feature_flags as _core_feature_flags _mgr_flags = ( _core_feature_flags.SERVER_FEATURE_FLAGS .setdefault("extension", {}) .setdefault("manager", {}) ) _mgr_flags["supports_csrf_post"] = True except ImportError: pass # older ComfyUI core without comfy_api.feature_flags ``` `.setdefault` chain coexists with the pre-existing `extension.manager.supports_v4` (hardcoded in core). Delivery: ComfyUI core pushes `SERVER_FEATURE_FLAGS` via the WebSocket handshake (see `server.py:296`) and via `GET /api/feature_flags` (see `server.py:689`). Clients use their existing feature-flag infrastructure; no new endpoint on the Manager side. ## Test plan - [x] `python -m py_compile comfyui_manager/__init__.py` → OK - [x] Smoke test (mocked `comfy_api.feature_flags` with a pre-seeded `supports_v4=True`): setdefault chain preserves `supports_v4` and writes `supports_csrf_post=True` → final dict exactly `{'extension': {'manager': {'supports_v4': True, 'supports_csrf_post': True}}}` - [x] `ruff check comfyui_manager/ --config ruff.toml` → All checks passed - [x] `pytest tests/ --ignore=tests/e2e --ignore=tests/playwright --ignore=tests/common/test_git_helper.py -q` → 206 passed, 12 skipped (no regression) - [x] `grep ^version pyproject.toml` → `version = "4.2.1"` - [ ] CI: Code Quality / Ruff / OpenAPI spec / E2E (ubuntu/macOS/Windows) ## Related - #2818 — 4.2 baseline CSRF hardening. This PR supplies the capability probe that follow-up frontend work (cmfront PR#11520) will use to decide its UX. - cmfront-team proposed and confirmed the flag name `extension.manager.supports_csrf_post`. ## References - Reported-by: XlabAI Team of Tencent Xuanwu Lab - CVSS: 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-28 21:12:47 +00:00