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

[ltdrdata]

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 fix(security): harden CSRF with Content-Type gate and expand E2E coverage #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)

Related

• fix(security): harden CSRF with Content-Type gate and expand E2E coverage #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)