2023-12-04 18:20:46 +00:00
|
|
|
package service
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
_ "embed"
|
|
|
|
|
"encoding/json"
|
2024-03-10 21:31:24 +00:00
|
|
|
|
2025-09-19 08:05:43 +00:00
|
|
|
"github.com/mhsanaei/3x-ui/v2/util/common"
|
|
|
|
|
"github.com/mhsanaei/3x-ui/v2/xray"
|
2023-12-04 18:20:46 +00:00
|
|
|
)
|
|
|
|
|
|
2025-09-20 07:35:50 +00:00
|
|
|
// XraySettingService provides business logic for Xray configuration management.
|
|
|
|
|
// It handles validation and storage of Xray template configurations.
|
2023-12-04 18:20:46 +00:00
|
|
|
type XraySettingService struct {
|
|
|
|
|
SettingService
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *XraySettingService) SaveXraySetting(newXraySettings string) error {
|
Fix blank Xray Settings page from wrapped xrayTemplateConfig (#4059) (#4069)
`getXraySetting` builds its response as
{ "xraySetting": <db value>, "inboundTags": ..., "outboundTestUrl": ... }
and embeds the raw DB value as the `xraySetting` field without
checking whether the stored value already has that exact shape.
The frontend pulls the textarea content from `result.xraySetting`
and saves it back verbatim. If the DB ever ends up holding the
response-shaped wrapper instead of a real xray config (older
installs where this happened at least once, users who imported a
copy-pasted response into the textarea, a botched migration, etc.),
the next save nests another layer, the one after that nests a
third, and the Vue-side JSON.parse of the resulting blob silently
fails — the Xray Settings page goes blank.
Fix both ends of the round-trip:
* Add `service.UnwrapXrayTemplateConfig`. It peels off any number of
`xraySetting`-keyed layers, leaving a real xray config behind.
The check is conservative: if the outer object already contains
any top-level xray key (`inbounds`, `outbounds`, `routing`, `api`,
`dns`, `log`, `policy`, `stats`), it is returned unchanged, and
there is a depth cap to avoid pathological inputs.
* `SaveXraySetting` unwraps before validation so a round-tripped
wrapper from an already-corrupted page can no longer re-poison
the DB on save.
* `getXraySetting` unwraps on read and, when it finds a wrapper,
rewrites the DB with the corrected value. Existing broken installs
heal themselves on the next visit to the page.
Includes unit tests for the passthrough, single-wrap, multi-wrap,
string-encoded-inner, and false-positive cases.
Co-authored-by: pwnnex <eternxles@gmail.com>
2026-04-21 18:30:02 +00:00
|
|
|
// The frontend round-trips the whole getXraySetting response back
|
|
|
|
|
// through the textarea, so if it has ever received a wrapped
|
|
|
|
|
// payload (see UnwrapXrayTemplateConfig) it sends that same wrapper
|
|
|
|
|
// back here. Strip it before validation/storage, otherwise we save
|
|
|
|
|
// garbage the next read can't recover from without this same call.
|
|
|
|
|
newXraySettings = UnwrapXrayTemplateConfig(newXraySettings)
|
2023-12-04 18:20:46 +00:00
|
|
|
if err := s.CheckXrayConfig(newXraySettings); err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
|
|
|
|
return s.SettingService.saveSetting("xrayTemplateConfig", newXraySettings)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *XraySettingService) CheckXrayConfig(XrayTemplateConfig string) error {
|
|
|
|
|
xrayConfig := &xray.Config{}
|
|
|
|
|
err := json.Unmarshal([]byte(XrayTemplateConfig), xrayConfig)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return common.NewError("xray template config invalid:", err)
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
}
|
Fix blank Xray Settings page from wrapped xrayTemplateConfig (#4059) (#4069)
`getXraySetting` builds its response as
{ "xraySetting": <db value>, "inboundTags": ..., "outboundTestUrl": ... }
and embeds the raw DB value as the `xraySetting` field without
checking whether the stored value already has that exact shape.
The frontend pulls the textarea content from `result.xraySetting`
and saves it back verbatim. If the DB ever ends up holding the
response-shaped wrapper instead of a real xray config (older
installs where this happened at least once, users who imported a
copy-pasted response into the textarea, a botched migration, etc.),
the next save nests another layer, the one after that nests a
third, and the Vue-side JSON.parse of the resulting blob silently
fails — the Xray Settings page goes blank.
Fix both ends of the round-trip:
* Add `service.UnwrapXrayTemplateConfig`. It peels off any number of
`xraySetting`-keyed layers, leaving a real xray config behind.
The check is conservative: if the outer object already contains
any top-level xray key (`inbounds`, `outbounds`, `routing`, `api`,
`dns`, `log`, `policy`, `stats`), it is returned unchanged, and
there is a depth cap to avoid pathological inputs.
* `SaveXraySetting` unwraps before validation so a round-tripped
wrapper from an already-corrupted page can no longer re-poison
the DB on save.
* `getXraySetting` unwraps on read and, when it finds a wrapper,
rewrites the DB with the corrected value. Existing broken installs
heal themselves on the next visit to the page.
Includes unit tests for the passthrough, single-wrap, multi-wrap,
string-encoded-inner, and false-positive cases.
Co-authored-by: pwnnex <eternxles@gmail.com>
2026-04-21 18:30:02 +00:00
|
|
|
|
|
|
|
|
// UnwrapXrayTemplateConfig returns the raw xray config JSON from `raw`,
|
|
|
|
|
// peeling off any number of `{ "inboundTags": ..., "outboundTestUrl": ...,
|
|
|
|
|
// "xraySetting": <real config> }` response-shaped wrappers that may have
|
|
|
|
|
// ended up in the database.
|
|
|
|
|
//
|
|
|
|
|
// How it got there: getXraySetting used to embed the raw DB value as
|
|
|
|
|
// `xraySetting` in its response without checking whether the stored
|
|
|
|
|
// value was already that exact response shape. If the frontend then
|
|
|
|
|
// saved it verbatim (the textarea is a round-trip of the JSON it was
|
|
|
|
|
// handed), the wrapper got persisted — and each subsequent save nested
|
|
|
|
|
// another layer, producing the blank Xray Settings page reported in
|
|
|
|
|
// issue #4059.
|
|
|
|
|
//
|
|
|
|
|
// If `raw` does not look like a wrapper, it is returned unchanged.
|
|
|
|
|
func UnwrapXrayTemplateConfig(raw string) string {
|
|
|
|
|
const maxDepth = 8 // defensive cap against pathological multi-nest values
|
|
|
|
|
for i := 0; i < maxDepth; i++ {
|
|
|
|
|
var top map[string]json.RawMessage
|
|
|
|
|
if err := json.Unmarshal([]byte(raw), &top); err != nil {
|
|
|
|
|
return raw
|
|
|
|
|
}
|
|
|
|
|
inner, ok := top["xraySetting"]
|
|
|
|
|
if !ok {
|
|
|
|
|
return raw
|
|
|
|
|
}
|
|
|
|
|
// Real xray configs never contain a top-level "xraySetting" key,
|
|
|
|
|
// but they do contain things like "inbounds"/"outbounds"/"api".
|
|
|
|
|
// If any of those are present, we're already at the real config
|
|
|
|
|
// and the "xraySetting" field is either user data or coincidence
|
|
|
|
|
// — don't touch it.
|
|
|
|
|
for _, k := range []string{"inbounds", "outbounds", "routing", "api", "dns", "log", "policy", "stats"} {
|
|
|
|
|
if _, hit := top[k]; hit {
|
|
|
|
|
return raw
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// Peel off one layer.
|
|
|
|
|
unwrapped := string(inner)
|
|
|
|
|
// `xraySetting` may be stored either as a JSON object or as a
|
|
|
|
|
// JSON-encoded string of an object. Handle both.
|
|
|
|
|
var asStr string
|
|
|
|
|
if err := json.Unmarshal(inner, &asStr); err == nil {
|
|
|
|
|
unwrapped = asStr
|
|
|
|
|
}
|
|
|
|
|
raw = unwrapped
|
|
|
|
|
}
|
|
|
|
|
return raw
|
|
|
|
|
}
|