Add Xray 26.6.22+ sessionID compatibility across backend, subscriptions, and the dashboard, and makes the editor/version checks depend on the node's actual Xray version#671
Conversation
fix: detect admins.id type at runtime in api_keys migration
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
First this version of xray is still pre release and there is no warranty this be the same in stable version. |
…se core versions - Remove migrate_core_xhttp_session_keys_if_sole_node() and its call site in update_node_status(): the panel was silently rewriting an admin's stored Xray core JSON (sessionPlacement/sessionKey -> sessionIDPlacement/ sessionIDKey) as soon as any node reported Xray >= 26.6.22, with no confirmation. This is redundant on top of the per-push rename already done in NodeOperation.connect_node (which translates a deep copy at the moment config is sent to a node, based on that node's own version) and the dual-name read fallback in XRayConfig/subscription builders, so removing it costs no functionality while no longer touching admin data behind their back. - update-core-modal.tsx: warn when the selected/entered core version is a pre-release or numerically above the latest stable release, separate from the existing sessionID breaking-change warning.
…nt Xray versions
node-modal.tsx: when selecting a Core Config, fetch the other nodes already
using it (useGetNodes({ core_id })) and show a muted, non-blocking hint if
their reported Xray versions differ — that core is pushed to every node
unmodified except for the handful of fields the panel already translates
per node version, so anything else version-specific can behave differently
across them. Kept as a warning rather than a hard block, consistent with
not forcing changes on the admin's data.
get_xray_version_by_core_id previously picked an unordered .limit(1) row when a core config is shared by multiple nodes, so the core-editor's version-aware gating (e.g. Session ID Table/Length visibility) could pin to an arbitrary sibling node's version instead of the one actually being configured. Now it picks the highest reported version among all nodes on that core, so the editor never hides a capability a real node on the core actually supports; the admin is separately warned elsewhere when nodes on a shared core report different versions.
…op redundant block
- Restyle the pre-release-version warning to match the removed
breaking-change warning's amber styling instead of blue, so there's one
consistent look instead of two stacked warnings when both applied.
- Drop the breaking-change warning's own UI block; the version-threshold
check it was built on (isBreaking) stays, since the backend still
requires `confirm: true` when actually crossing the sessionID-rename
boundary — only the now-redundant dedicated banner is gone.
- Fix an unclear ru translation ("боевых нодах" → "продакшен-нодах").
|
@M03ED
Added a non-blocking warning when the selected/entered version is a pre-release (or above current latest stable). It also covers the 26.6.22 sessionID-rename crossing — that used to be its own separate banner, but since practically every version past 26.4.13 is pre-release anyway, showing two stacked warnings for the same underlying situation was redundant, so I folded it into this one. This isn't just caution — it has a real use case. Xray-core's e10347bf (v26.6.22) added SessionIDTable/SessionIDLength, the only way to stop XHTTP from putting a UUID in the request path — which a growing number of CDNs in Russia now filter on (and a lot of people were begging Xray-core's developers to merge that feature). I checked the officially published @pasarguard/xray-config-kit@0.3.4 (what dev actually depends on) directly: it doesn't know these fields exist at all — silently drops them in permissive mode, refuses to compile in strict mode, and its parity data doesn't go past v26.5.3. So today, on upstream, this isn't just untested — it's unreachable through the panel regardless of the node's actual Xray version. That's the concrete reason to track a version this new.
Removed migrate_core_xhttp_session_keys_if_sole_node() entirely — it silently rewrote the admin's stored core config in the DB. The DB is never touched without an explicit admin action now. What's left is a transient, non-persisted rename (rename_xhttp_session_keys in NodeOperation.connect_node) applied only to the copy pushed to a given node, never written back to the DB. Same pattern the codebase already uses for Xray-core's earlier splithttp → xhttp rename (app/subscription/clash.py). Without it, an admin's configured sessionPlacement/sessionKey would silently stop applying once a node crosses 26.6.22. That said, I'm not attached to it — happy to just remove it too if you'd rather the panel not touch the outgoing config at all.
No hard block, but the node editor now warns when a Core Config is shared with nodes reporting a different Xray version. |
checkSessionIdRoomSize() and its three call sites (Hosts form, inbound editor, profile-level persist check) previously skipped validation whenever either sessionIDTable or sessionIDLength was missing, treating it as "nothing to check yet". That's only true in one direction: Xray-core only runs this check when sessionIDTable is set at all (infra/conf/ transport_internet.go gates the whole block on `c.SessionIDTable != ""`), but once a table is set there's no default for sessionIDLength — an unset or invalid length hits the same Build()-time error as a too-small range. A table configured without a length now gets flagged instead of silently saving a config Xray would refuse to start.
|
Is it okay now? Or something needs to be changed/fixed? |
2 participants
This branch adds Xray 26.6.22+ sessionID compatibility across backend, subscriptions, and the dashboard, and makes the editor/version checks depend on the node's actual Xray version.
xray_version/node_versiondata for nodes, and exposexray_versiononGET /api/core/{id}so the dashboard can make version-aware decisionssessionPlacement/sessionKey->sessionIDPlacement/sessionIDKeyrename across backend config parsing, subscription generation, node upgrade flow, and automatic stored-config migration when a sole node crosses the 26.6.22 thresholdsessionIDTable/sessionIDLengthcontrols to the Hosts UI, including locale stringscoreXrayVersion, includingechForceQuerygating and theallowInsecurehard-error warningsessionIDTable/sessionIDLengthroom-size validation across the Hosts form, inbound dialog, and raw-JSON persist validationDependency Note
dashboard/package.jsoncurrently uses a temporary testing dependency:@pasarguard/core-kitis aliased tonpm:@funlay/core-kit-beta@0.3.0-beta.1, and that build resolves@pasarguard/xray-config-kittonpm:@funlay/xray-config-kit-beta@0.4.0-beta.1indashboard/bun.lock. Before merge, both must be repointed to the official published@pasarguard/*packages, please.Checked
bun run testpasses (19/19), and typecheck is clean for all touched frontend filesuv run pytest tests/api/test_node.py tests/test_subscription_clash_xhttp.py -vis green for the sessionID /xray_versioncoverage in this branchtest_get_nodes_simple_*failures (KeyError: 'access_token') are pre-existing ondev, not introduced herexray_version/node_versioncolumns already exist ondeven/ru/fa/zhare syntactically valid and include the newcoreEditor.inbound.xhttp.*keysechForceQuery/allowInsecuregates on nodes with different Xray versions