11 Commits

Author	SHA1	Message	Date
nima1024m	9e13b32c34	fix: make all self-managed file downloads/installs atomic, with real completion status (#5711) ... * fix(script): download the live x-ui.sh script atomically before replacing it update_menu(), update_shell(), and update.sh's update_x-ui() all overwrote /usr/bin/x-ui in place via `curl -o`, truncating and rewriting the same inode a currently-running x-ui process may still be reading from. A network hiccup or slow write during that overwrite leaves a half-old/half-new script on disk, which then fails with bogus syntax errors on the next run. Download to /usr/bin/x-ui-temp and `mv -f` into place instead, matching the atomic pattern install.sh already uses. Also fixes update_menu() checking chmod's exit code instead of curl's, which meant a failed download could still report "Update successful." * fix(script): close remaining gaps in the atomic script-update path Code review of the previous commit found the atomic mv fix was itself incomplete: - None of the mv -f calls checked their exit status, so a failed move fell through to chmod and "success" messaging while /usr/bin/x-ui stayed on the old file. - update_shell()'s `[[ -s x-ui-temp ]]` guard couldn't tell "curl -z got a 304, nothing to do" from "a stale temp file survived an earlier crashed run" -- the latter could get moved into place with no freshness check. - update_menu(), update_shell(), and update_x-ui() all hardcoded the same /usr/bin/x-ui-temp path, so two concurrent updates (e.g. a cron auto-update racing an interactive menu update) could collide. - update.sh's update_x-ui() was missing the non-empty-file guard update_shell() already had. x-ui.sh's update_menu() and update_shell() now share a replace_xui_script() helper that uses a PID-suffixed temp path (/usr/bin/x-ui-temp.$$), pre-cleans it before every attempt, and checks the exit status of curl, the non-empty test, and mv before treating the update as successful. update.sh's update_x-ui() gets the same sequence inlined (it's fetched as a standalone script and can't call x-ui.sh's function), closing the missing-guard gap and using its own unique temp path. * fix(script,panel): harden the remaining self-update download paths install.sh had the same unguarded /usr/bin/x-ui-temp overwrite the two already-fixed scripts had: no exit-status check on mv, and a fixed temp name shared with x-ui.sh/update.sh's (now-unique) temp files. Give it its own PID-suffixed temp path, an empty-file guard, and an mv exit-status check, matching the pattern used there. Audited the web dashboard's Go-native updater (panel.go) for the same bug class: it already uses os.CreateTemp for a genuinely unique temp file and cleans up via both a deferred Remove and a shell EXIT trap, so it was never exposed to the fixed-path race. It was missing a check for a zero-byte download (a 200 OK with an empty body would chmod +x and exec an empty script) -- added that alongside the existing size cap. Not addressed here: once startUpdate()'s child process starts, the Go service releases it and returns success immediately. If update.sh fails partway through, the still-running old panel keeps answering /status, so the frontend's poll can report success with no update having happened. Fixing that needs update.sh to signal completion status back and the frontend to check it -- a separate follow-up. * feat(panel): report real completion status for the web self-update Fixes the fire-and-forget gap flagged in the atomic-overwrite fix: once startUpdate() launches update.sh detached, the Go service had no way to learn whether it actually succeeded. If update.sh failed partway (network drop, disk full, permission denied), the still-running old panel kept answering /status, so the frontend's poll reported success with nothing having changed. update.sh now writes its outcome to a small JSON status file (/etc/x-ui/update-status.json by default) via `trap ... EXIT`, which covers every exit path in the script -- including the two bare `exit 1` call sites that don't go through the existing _fail() helper. The Go service generates a run ID before launching, passes it and the status path to update.sh via XUI_UPDATE_RUN_ID/XUI_UPDATE_STATUS_FILE, and a new GET /panel/api/server/getUpdateStatus endpoint reports it back. The frontend now polls that instead of blindly trusting HTTP reachability, and shows a distinct error or "couldn't confirm" message instead of silently reloading into a false success. Adversarial review of this surfaced three more issues, fixed here: - No lock stopped two concurrent /updatePanel calls from launching two update.sh runs that would race each other on the actual update work (tar extraction, service unit swap). Added an in-memory guard with a 5-minute self-expiring window, so a run that never reaches a terminal state doesn't lock out retries indefinitely. - XUI_UPDATE_RUN_ID is read from the environment and was interpolated unquoted into the status JSON; a malformed value would produce invalid JSON. Now validated as digits-only before use. - The run ID is a UnixNano timestamp (19 digits), sent as a raw JSON number it would lose precision in JavaScript (past Number.MAX_SAFE_INTEGER), letting two different runs round to the same value on the wire and defeat the whole comparison. It's now a decimal string end to end (Go, the status file, and the generated frontend type). install.sh's equivalent temp-file/mv path and the Go-native downloadPanelUpdater() path were audited for the same bug classes during this work; findings from that audit were addressed separately. * fix(panel): release the update lock as soon as the run finishes An exhaustive multi-angle review of the whole branch (12 finder angles, 3-vote adversarial verification, a fresh-eyes sweep) surfaced a real bug in the concurrency guard added in the previous commit, plus several smaller issues; this fixes what's actionable now. The bug: acquireUpdateSlot only ever released on the 5-minute stale timeout or if launching itself failed. If update.sh launched fine but failed fast (bad GitHub API response, "x-ui not installed", any of its early exit paths), the status file correctly reported "failed" within seconds, but a retry was still rejected with "a panel update is already in progress" for up to 5 more minutes -- the guard never looked at the very status file this branch built to know a run was done. It now tracks which run ID currently holds the slot and checks that run's own status before falling back to the timeout, so a fast failure clears the way for an immediate retry. Added a regression test for this, plus one confirming a stale, unrelated runID can't be mistaken for the current run finishing. Also: - Added a genuinely concurrent test for the guard: 200 goroutines racing acquireUpdateSlot, asserting exactly one wins. The previous tests only ever called it from one goroutine, so they gave no signal if the mutex's check-then-set were silently broken -- verified this by temporarily removing the lock and confirming the old tests still passed while the new one caught it immediately under -race. - Removed the redundant upfront "pending" status write: GetUpdateStatus already defaults a missing/stale file to pending, and the frontend matches by run ID regardless, so the write changed no observable behavior. Deleted writeUpdateStatus entirely since that was its only caller. - Renamed replace_xui_script()'s unclear "conditional" parameter to use_if_modified_since, matching what it actually controls. - Added HTTP-level tests for the new getUpdateStatus endpoint, including a regression test that the runId wire format is a JSON string (decoding into a Go string field fails outright if it were ever a bare number). updatePanel's actual launch path is not covered: on a Linux test runner it would make a real network call and could exec a real update.sh, so only its non-Linux guard path is safely testable without mocking. Not fixed here, tracked separately: the same unsafe-overwrite pattern this branch eliminated for /usr/bin/x-ui is still present for the systemd unit file install in update.sh and install.sh (lower severity since systemd only reads it on daemon-reload, not continuously); and startUpdate's systemd-run-vs-detached-fallback branching has no test coverage since testing it safely needs dependency injection this fix doesn't warrant bundling in. * fix(script): make systemd unit file installation atomic Same anti-pattern as the /usr/bin/x-ui overwrite fixed earlier: every site that lands the systemd unit at ${xui_service}/x-ui.service -- copying it from the extracted release tarball, or falling back to a GitHub download per distro family -- wrote straight onto the live path via cp/curl, no temp file, no verification. A network drop mid-download or an interrupted cp leaves the unit file truncated; systemd then fails to parse it on the next daemon-reload/start, leaving the panel unable to come up until an operator manually re-copies a good unit file. Lower severity than the /usr/bin/x-ui case (systemd only reads this file on demand at daemon-reload time, not continuously the way bash interprets a running script line by line), but it's the identical gap, just left uncovered when that fix landed. Added a small shared helper in both update.sh and install.sh -- _install_xui_service_unit() -- covering both source types (cp from the tarball, curl from GitHub): write to a PID-suffixed temp file, verify the copy/download succeeded and the result is non-empty, then mv -f into place and check that exit status too, matching the pattern already used for /usr/bin/x-ui. All 4 cp sites and the 3-way curl fallback in each file now go through it; verified no other site writes new content to the unit path (the remaining ${xui_service} references are a pre-install existence check, an rm during old-version cleanup, and the chown/chmod that already ran after the file is safely in place -- none of those need atomicity). Verified with bash -n on both files, plus a standalone scratch test exercising cp-success, cp-with-missing-source, cp-with-empty-source, and curl-failure paths: on every failure the previous, good unit file content is left untouched and no temp file is leaked behind. * fix(script): make Alpine's OpenRC init script install atomic; drop a stray comment A final maximum-rigor review of the whole PR (12 finder angles including a repo-wide sweep for any remaining instance of the bug class this PR fixes) found two more real issues: - Alpine's /etc/init.d/x-ui startup script is downloaded via a bare `curl -fLRo` straight onto the live path in both update.sh and install.sh -- the exact same unguarded-overwrite pattern already fixed for /usr/bin/x-ui and the systemd unit file, just left uncovered on the OpenRC side. A network drop mid-download truncates the live init script; OpenRC then fails to source/execute it on the next start, leaving the panel unable to come up. Fixed with the same temp-file + non-empty check + mv -f (with its own exit-status check) pattern used everywhere else in this PR. Verified with bash -n and a standalone scratch-script test covering success, empty-download, and destination-preserved-on-failure paths. - internal/web/service/panel/panel_test.go had one line-level `//` comment on a call site, which the root CLAUDE.md's hard rule ("No // line comments in committed Go/TS... rename instead of annotating") explicitly prohibits. The comment duplicated context already stated in the test's own doc comment two lines above, so it's simply removed rather than reworded. Also flagged, deliberately not bundled here since it's a different subsystem: x-ui.sh's update_geofiles() downloads Xray's live geoip.dat/geosite.dat with the same unguarded curl -o pattern. Tracked as its own follow-up. * fix(script): make geo-data file downloads atomic Same anti-pattern as /usr/bin/x-ui, the systemd unit file, and the Alpine init script fixed in prior PRs: update_geofiles() downloaded Xray's live geoip.dat/geosite.dat (and the IR/RU variants) with curl writing straight onto the exact path Xray reads at runtime (internal/xray/process.go's GetGeoipPath/GetGeositePath), no temp file, no verification. The existing check only inspected the reported HTTP status via -w '%{http_code}', not file integrity, so a network drop mid-download could leave a truncated .dat file on disk that passes the status check. Xray then fails to parse it on the next restart/reload, breaking any routing rules that reference geoip:/ geosite:. The -z conditional-GET usage needed care here: the original code pointed both -z and -o at the same live path. Fixed by pointing -z at the live file (to keep the "already current" freshness check) while -o writes to a PID-suffixed temp file, matching the pattern already proven in x-ui.sh's replace_xui_script(). Verified with a local HTTP server that a 304 response leaves the temp file untouched/nonexistent (so the existing "already up to date" branch still works unchanged), and added a non-empty check plus a checked mv -f before treating a download as installed. Verified with bash -n and an end-to-end scratch test against a local server covering: fresh download, 304-not-modified, empty response body, and a 404 -- confirming a failure at any stage leaves the previous good .dat file completely untouched and no temp file behind. * fix(script): verify the release tarball extraction, not just the download The final maximum-rigor review found the most significant remaining gap in this whole effort: update.sh and install.sh check the tarball download's exit status, but never check tar's exit status, and never verify the extracted x-ui binary actually exists before continuing. Worse, by the time extraction runs, the previous installation has already been stopped and deleted -- there's no rollback. A truncated download that still passes curl's own check, or a tar failure (disk full, killed process), left the panel silently in a broken half-state: chmod/config/service-install all continued to run against a missing or empty binary, with no error surfaced anywhere. This is the same bug class as everything else in this PR (unverified write to a path something then depends on), just for the tarball itself rather than a single file -- and it also covers the geo-data files this PR already fixed once for the interactive/cron path, since they ship inside this same tarball on every panel update. Added: a non-empty check on the downloaded archive (both files, both install.sh call sites) and a check that tar succeeded and produced a non-empty x-ui binary before proceeding, failing loudly with a message that explicitly says the previous install is already gone, since silently continuing here is worse than anywhere else in this PR. This doesn't make the multi-file extraction fully atomic (that would mean extracting to a temp directory and atomically swapping the whole install tree into place, a materially larger restructuring than anything else in this PR) -- but it closes the "fails silently, user discovers it days later when Xray can't start" gap, which was the actual reported problem this whole effort traces back to. Also fixed, all much smaller: - replace_xui_script() in x-ui.sh implicitly returned chmod's exit status instead of success, so a successful atomic install could be reported as failed if chmod transiently failed after the mv already landed the new script. Added an explicit `return 0`. - update_geofiles() had no default case branch; an unrecognized argument would silently reuse whatever dat_files/dat_source values a previous call left in the un-scoped globals instead of failing. Currently unreachable (all three call sites pass fixed literals) but cheap, defensive, and worth having. - internal/web/controller/server.go's updatePanel has one branch (an unparseable "dev" form value) that's both untested and safe to test on any platform, since it's rejected before any real exec/network call. Added the missing test case. Verified: bash -n on all three scripts; an empirical scratch test covering an empty downloaded archive, a corrupt (non-gzip) archive, and a successfully-extracting-but-empty archive, confirming each is caught before the script proceeds; full go build/vet/test -race across the whole module; frontend generation confirmed still in sync. * fix(panel): base the update-slot staleness fallback on process liveness Addresses the automated review on the upstream PR (MHSanaei/3x-ui#5711). Blocking finding: acquireUpdateSlot's staleness fallback freed the update slot purely on elapsed wall-clock time (5 minutes), with no check on whether the update.sh process it launched was actually still running. update.sh runs install_base() (apt-get/dnf/pacman update and install) before update_x-ui even starts, plus several GitHub downloads (release tarball, x-ui.sh, and possibly a service unit or x-ui.rc) -- on a slow or throttled host, a small VPS being the typical deployment target for this project, that alone can plausibly exceed 5 minutes with nothing wrong. A second /updatePanel call arriving in that window (an admin retrying after the frontend's 90s poll times out, or overlapping master-node bulk-update calls) would launch a second update.sh, racing the exact rm/tar/mv/systemctl sequence this whole PR exists to make safe. Fixed by recording the launched process's PID (detached-fallback path only; the systemd-run path's own process has already exited by the time startUpdate returns, so it never learns update.sh's real PID) and checking it via the standard POSIX kill(pid, 0) liveness probe before treating a run as stale, following the existing panel_unix.go / panel_other.go platform-split pattern already used for setDetachedProcess. A confirmed-alive process now keeps the slot held past updateStaleAfter (raised from 5 to 20 minutes as a safer baseline for the systemd-run path, which still has no way to check liveness directly). updateHardCeiling (2 hours) is an absolute backstop so a genuinely wedged run can never lock out retries permanently even on the PID-tracked path. Added two regression tests exercising the new logic (gated to Linux, since processAlive is a no-op stub elsewhere): a live PID keeps the slot held past the stale window, and the hard ceiling overrides liveness. Traced both by hand against the new acquireUpdateSlot logic; could not execute-verify processAlive itself on this Windows dev machine (no WSL distro installed, and installing one felt disproportionate to validate kill(pid, 0), an extremely well-established POSIX primitive), but cross-compiled clean for linux/amd64 and this repo's CI runs the real test suite on Linux. Also fixed, both suggestions from the same review: - install.sh: two failure paths right after tarball extraction were exiting without cleaning up the already-downloaded x-ui.sh temp file (xui_script_temp), leaving it behind. Every other new failure branch in this PR removes its temp file before exiting; these two now do too. - frontend/src/pages/api-docs/endpoints.ts: updatePanel's doc entry did not reflect that a successful response now carries an obj with runId. Added an inline response example matching the existing pattern used for other ad hoc (non-schema-backed) responses like getWebCertFiles. Verified: go build/vet clean on both windows (native) and a linux/amd64 cross-compile; full go test ./... clean; go test -race on the panel and controller packages; bash -n on all three shell scripts; npm run gen confirms the openapi.json diff is exactly the new response example with no stray changes to src/generated; TestAPIRoutesDocumented still passes.	2026-07-02 18:19:33 +02:00
MHSanaei	fa1a19c03c	style: adopt golangci-lint v2 and resolve all findings ... Add .golangci.yml (v2): the standard linters plus bodyclose, errorlint, noctx, misspell, rowserrcheck, sqlclosecheck, unconvert, usestdlibvars, with gofumpt + goimports formatters. Enable the std-error-handling exclusion preset for idiomatic Close/Remove/Setenv ignores; scope-exclude SA1019 (parser.ParseDir in tools/openapigen) and ST1005 (intentional capitalized user-facing error copy that tests assert verbatim). No inline nolint directives were introduced. Resolve all 217 findings behavior-preserving: gofumpt/goimports formatting, explicit blank assignment on intentionally ignored errors, errors.Is/errors.As and %w wrapping, context-aware stdlib calls (CommandContext/QueryContext/NewRequestWithContext/Dialer), staticcheck simplifications, removed redundant conversions, http.StatusOK and http.MethodGet, inlined the go:fix intPtr helper, and deferred sql rows Close. Add a golangci CI job mirroring the existing Go jobs.	2026-06-27 15:42:22 +02:00
MHSanaei	6964d84742	feat(reality): add live REALITY target scanner with IP/CIDR discovery ... Replace the static reality-targets list with a server-side TLS 1.3 probe that checks TLS 1.3 + HTTP/2 + X25519 + a trusted certificate. - Single-domain validate auto-fills target and serverNames from the cert SAN - Discovery scans an IP/CIDR without SNI to find new targets from their certificates, deduped and ranked by feasibility then latency, private-IP guarded via netsafe - New endpoints scanRealityTarget and scanRealityTargets with RealityScanResult, plus openapigen and api-docs entries - Add scanner strings to all 13 locales - Replace deprecated AntD Alert message prop with title across the panel	2026-06-26 22:18:47 +02:00
MHSanaei	e8878b71a4	feat(nodes): add Dev channel option to node panel updates ... The node update confirm dialog now offers a 'Dev channel (latest commit)' choice. The dev flag threads master -> nodes/updatePanel -> UpdatePanels -> remote.UpdatePanel -> the node's updatePanel endpoint, which calls StartUpdateChannel(dev) to install the rolling dev-latest build. With no dev flag the node keeps following its own channel setting.	2026-06-25 00:29:03 +02:00
MHSanaei	1d1128cf94	fix(update): read setUpdateChannel body as form field, not JSON ... The panel's axios layer posts application/x-www-form-urlencoded, so the dev-channel toggle sent dev=true and ShouldBindJSON failed with 'invalid character d'. Parse c.PostForm("dev") to match the codebase's form-encoded POST convention.	2026-06-24 18:24:54 +02:00
MHSanaei	aad2b3eb1e	feat(update): add rolling dev update channel for per-commit builds ... Adds an opt-in Dev channel so panels running CI per-commit builds can self-update to the latest commit, mirroring the stable online-update flow. CI publishes/overwrites a single fixed-tag pre-release (dev-latest), force-moved to the newest main commit and marked --latest=false so releases/latest stays the stable tag. Builds stamp the short commit via -ldflags; the panel compares the running commit to the dev release commit to detect an update, and update.sh honors XUI_UPDATE_TAG to install from that tag. Linux/systemd only.	2026-06-24 18:11:22 +02:00
MHSanaei	dabd3f5d2b	feat(backup): prefer browser request host for backup filename ... Name downloaded DB backups after the host shown in the panel title (c.Request.Host) when available, falling back to the configured web domain and then the public IP. Telegram-sent backups have no request context and keep the domain/IP behavior.	2026-06-23 01:13:09 +02:00
MHSanaei	ce8b1bed77	feat(iplimit): gate IP limit on fail2ban and reset stale limits ... Per-client IP limit only enforces where fail2ban is installed, so the panel now reports enforceability and disables the field otherwise: - Add GET /panel/api/server/fail2banStatus (enabled/installed/usable/windows), cached 30s. - ClientFormModal and ClientBulkAddModal disable the IP Limit input when not usable and show a hover tooltip; Windows gets a platform-specific message instead of the bash-menu hint. - One-time migration ResetIpLimitNoFail2ban zeroes existing client limitIp (inbound settings JSON + clients table) on hosts without fail2ban, where the limit never applied. - Drop the recurring '[LimitIP] Fail2Ban is not installed' warning. - Add limitIpFail2banMissing/limitIpFail2banWindows/limitIpDisabled across all 13 locales.	2026-06-22 23:15:58 +02:00
MHSanaei	a7e959ff49	feat(backup): name DB backup files after the server address ... Panel downloads and Telegram backups were always named x-ui.db / x-ui.dump, so backups from different servers were indistinguishable. Name them after the panel address instead: the configured web domain, or the public IP (IPv4 before IPv6) when no domain is set, falling back to x-ui. Centralized in ServerService.BackupFilename(); host is sanitized to the getDb filename charset (IPv6 colons become hyphens) and read from the mutex-guarded LastStatus to avoid racing the status goroutine.	2026-06-22 21:55:58 +02:00
MHSanaei	7c8889466b	feat(tls,reality): port xray TLS/REALITY fields, cert-hash helpers, fallback UX ... TLS: add verifyPeerCertByName (vcn) to inbound settings + emit in both share-link generators (frontend + Go sub) and outbound parser; the allowInsecure replacement xray removed after 2026-06-01. Add server-side curvePreferences, masterKeyLog, echSockopt (passthrough + form) at tlsSettings top-level so they survive the panel-only settings strip. REALITY: add limitFallbackUpload/Download (afterBytes/bytesPerSec/burstBytesPerSec) with per-field tooltips, plus masterKeyLog. Verified field names/semantics against pinned xray v1.260327.1 (bytesPerSec=0 disables). Hosts: fix verify_peer_cert_by_name column bool->string (xray expects comma-separated names) with an idempotent, history-gate-free migration (SQLite typeof blank; Postgres ALTER once); emit vcn for hosts/external proxies. Server: add getCertHash (local cert DER SHA-256) and getRemoteCertHash (xray tls ping) endpoints + api-docs; wire pinned-cert field buttons. Drop the meaningless random-hash button. Xray UI: metrics endpoint (listen/tag) config in Basics; import/export for routing rules and outbounds. Fallbacks card: compact empty state, header-aligned actions, responsive labeled grid rows. i18n: add all new keys to every locale; drop unused generateRandomPin.	2026-06-21 15:58:42 +02:00
Sanaei	41645255f1	refactor: focused service files, leaf subpackages, and an internal/ layout (#5167) ... * refactor(service): split client.go into focused files client.go had grown to 4455 lines mixing ~10 responsibilities. Split it verbatim into cohesive same-package files (no behavior change): client.go foundation: ClientService, ClientWithAttachments, ClientCreatePayload, ErrClientNotInInbound, sqlInChunk client_locks.go inbound mutation locks, delete tombstones, compactOrphans client_lookup.go read-only lookups (GetByID, List, EffectiveFlow, ...) client_link.go inbound association sync (SyncInbound, DetachInbound, ...) client_crud.go single-client CRUD + validation + protocol defaults client_inbound_apply.go low-level inbound-settings mutators + by-email setters client_bulk.go bulk attach/detach/adjust/delete/create + DelDepleted client_traffic.go traffic-reset paths client_groups.go client group management client_paging.go paged listing, filtering, sorting, summary Every declaration moved unchanged (verified: identical func/type/const/var signature set before vs after). Imports redistributed per file via goimports. go build ./..., go vet, and go test ./web/service/... all pass. * refactor(service): split inbound.go into focused files inbound.go was 4100 lines. Split it verbatim into cohesive same-package files (no behavior change): inbound.go core inbound CRUD + InboundService (keeps pkg doc) inbound_protocol.go protocol / stream capability helpers inbound_node.go node/runtime/remote coordination + online tracking inbound_traffic.go traffic accounting, reset, client stats inbound_client_ips.go per-client IP tracking inbound_clients.go client lookups within inbounds + copy-clients inbound_disable.go auto-disable invalid inbounds/clients inbound_migration.go DB migrations inbound_sublink.go subscription link providers inbound_util.go generic slice/string helpers Identical func/type/const/var signature set before vs after; package doc comment preserved on inbound.go. Imports redistributed via goimports. Build, vet, and go test ./web/service/... all pass. * refactor(service): split tgbot.go into focused files tgbot.go was 3738 lines dominated by a 1246-line answerCallback. Split it verbatim into cohesive same-package files (no behavior change): tgbot.go lifecycle, bot setup, caches, small utils tgbot_router.go incoming update / command / callback dispatch tgbot_send.go outbound messaging primitives tgbot_client.go client views, actions, subscription links tgbot_inbound.go inbound listing / pickers tgbot_report.go server usage, exhausted, online, backups, notifications Identical func/type/const/var signature set before vs after. Imports redistributed via goimports. Build, vet, and go test ./web/service/... pass. * refactor(client): dedupe single-field by-email setters ResetClientIpLimitByEmail, ResetClientExpiryTimeByEmail, and ResetClientTrafficLimitByEmail shared an identical ~50-line body that resolves the inbound by email, confirms the client exists, rewrites a single-client settings payload, and delegates to UpdateInboundClient. Extract that into applyClientFieldByEmail(inboundSvc, email, mutate) and reduce each setter to a 3-line wrapper. Behavior is unchanged: same checks and error strings, same single-client payload contract, same totalGB guard. SetClientTelegramUserID (resolves by traffic id, different error text) and ToggleClientEnableByEmail/SetClientEnableByEmail (different return shape and a pre-read of the old state) intentionally keep their own bodies. * refactor(service): extract panel/ subpackage Move the panel-administration leaf services out of the flat service package into web/service/panel/ (package panel): user.go UserService (auth / 2FA / LDAP) panel.go PanelService (restart / self-update) + version helpers panel_other.go non-unix RestartPanel panel_unix.go unix RestartPanel api_token.go ApiTokenService websocket.go WebSocketService panel_test.go version/shellQuote unit tests These are leaves: they depend on core (SettingService, Release) but no core file references them, so the extraction creates no import cycle. Core references are now qualified (service.SettingService, service.Release); callers in main.go, web/web.go, and web/controller/* updated to panel.*. Build, vet, and go test ./web/... pass. * refactor(service): extract integration/ subpackage Move the external-provider integration leaves into web/service/integration/ (package integration): warp.go WarpService (Cloudflare WARP) nord.go NordService (NordVPN) custom_geo.go CustomGeoService (custom geo asset management) *_test.go custom_geo / panel-proxy tests These depend on core (SettingService, ServerService, XraySettingService) but no core file references them. xray_setting.go stays in core because it calls the unexported SettingService.saveSetting. The shared isBlockedIP SSRF helper (used by core url_safety.go and by custom_geo) now has a small copy in each package rather than being exported. Core references qualified; callers in web/web.go, web/job/*, and web/controller/* updated to integration.*. Build, vet, and go test ./web/... pass. * refactor(service): extract tgbot/ subpackage Move the Telegram bot (6 files + test) into web/service/tgbot/ (package tgbot). It is a leaf: it embeds five core services (Inbound/Client/Setting/ Server/Xray) and the core never references it, so no import cycle. To support the package boundary without changing behavior: - core exposes XrayProcess() *xray.Process so tgbot keeps calling the exact same running-process methods it used via the package-level `p`; - three core methods tgbot calls are exported: ClientService.checkIs- EnabledByEmail -> CheckIsEnabledByEmail, InboundService.getAllEmails -> GetAllEmails (callers updated in-package); - tgbot's embedded-field types and the few core type refs (Status, ClientCreatePayload, SanitizePublicHTTPURL) are now service-qualified. Callers in main.go, web/web.go, web/job/*, and web/controller/* updated to tgbot.*. Build, vet, and go test ./web/... pass. * refactor(service): extract outbound/ subpackage OutboundService (outbound.go) imports only neutral packages (config, database, model, xray) and its production code is referenced by no core or sibling service file — only by web/controller/xray_setting.go and web/job/xray_traffic_job.go. Move it to web/service/outbound/ (package outbound); no core qualification needed inside. Callers updated to outbound.*. The one coupling was a tiny pure test helper, outboundsContainTag, used by both outbound.go and the core outbound_subscription_test.go; it now has a small copy in that test file rather than being shared across the boundary. Build, vet, and go test ./web/... pass. * refactor(util): move wireguard into its own subpackage util/wireguard.go was the lone file of the root `util` package (24 lines, one exported func GenerateWireguardKeypair), while every other util concern lives in a focused subpackage (util/common, util/crypto, util/netsafe, ...). Move it to util/wireguard/ (package wireguard) for consistency; its only importer, web/service/integration/warp.go, is updated. The root `util` package no longer exists. * refactor(sub): drop redundant sub prefix from filenames Inside package sub the subXxx.go prefix just repeats the package name (like client_*.go did inside service). Rename for consistency; content and type names are unchanged: subController.go -> controller.go subService.go -> service.go subClashService.go -> clash_service.go subJsonService.go -> json_service.go (+ matching _test.go files) * refactor(controller): rename xui.go -> spa.go XUIController serves the panel's single-page-app shell; spa.go names that role plainly (the other controller files are domain-named). File rename only — the type stays XUIController. api_docs_test.go keys route base paths by filename, so its "xui.go" case is updated to "spa.go". * refactor: move backend packages under internal/ Adopt the idiomatic Go application layout: the backend packages now live under internal/ (a boundary the toolchain enforces), signalling private implementation instead of a library-style flat root. No runtime behavior changes — only import paths and a few build/config paths move. Moved: config, database, logger, mtproto, sub, util, web, xray -> internal/. main.go stays at the repo root and tools/openapigen stays under tools/ (both still import internal/* because the internal rule keys off the module root). The module path github.com/mhsanaei/3x-ui/v3 is unchanged; 149 .go files had their import prefix rewritten to .../internal/<pkg>. Couplings the Go compiler can't see, updated to the new layout: - frontend i18n imports of web/translation (react.ts, setup.components.ts) - vite outDir + eslint/tsconfig ignore globs -> internal/web/dist - Dockerfile COPY paths for web/dist and web/translation - locale.go os.DirFS("web") disk fallback -> "internal/web" - .gitignore and ci.yml go:embed stub for internal/web/dist - api_docs_test.go repo-root relative walk (one level deeper) - tools/openapigen filesystem package paths; ApiTokenView repointed to the web/service/panel subpackage and codegen regenerated (clears a stale type the ci.yml codegen check was failing on) Verified: go build/vet/test (all packages), and frontend typecheck, lint, vitest (478 tests), and production build into internal/web/dist. * fix(config): keep test runs from writing logs into the source tree GetLogFolder() returns a CWD-relative "./log" on Windows. Under `go test` the working directory is each package's own folder, so InitLogger (called by tests in web/job, web/service, xray, web/websocket) created stray log/ directories scattered through the source tree (e.g. internal/web/job/log/). Redirect to a shared temp folder when testing.Testing() reports a test run. Production behavior is unchanged: Windows still uses ./log next to the binary and Linux /var/log/x-ui. The log files were always gitignored (*.log) and never committed; this just stops the noise at the source. * docs: move subscription-template guide out of root into docs/ sub_templates/ was a top-level folder holding only a README and no actual templates (3x-ui ships none by design), referenced nowhere and unlinked from any doc — it read like an empty placeholder cluttering the repo root. Move the guide to docs/custom-subscription-templates.md (a proper docs home), reword its intro to read as documentation rather than a folder note, link it from the Features list in README.md, and drop the empty sub_templates/ folder. * fix: update stale web/ path references after the internal/ move The internal/ migration rewrote Go import paths but left some references to the old top-level layout in docs, comments, and a few runtime disk paths. Functional (dev-mode only): the disk-serving fallbacks that read the Vite build from disk when running from source still pointed at web/dist/, which moved to internal/web/dist/ — so `os.DirFS`/`os.Stat`/`os.ReadFile` in internal/web/web.go and internal/sub/{sub,controller}.go are corrected. Production was unaffected (it serves the embedded FS; verified by the Docker build), but `go run` with a live frontend build silently fell back to embed. Docs/comments: frontend/README.md, CONTRIBUTING.md, the claude-issue-bot and release workflows, the openapigen -root help text, and assorted Go comments now reference internal/web, internal/database, internal/sub, internal/xray, etc. Package-name mentions (the "web" package), root paths (main.go, frontend/, install scripts, /etc/x-ui), routes (/panel/api/xray), and the historical "web/assets no longer exists" note were intentionally left as-is. * refactor(web): remove the legacy /xui -> /panel redirect middleware RedirectMiddleware existed only for backward compatibility with the old `/xui` URL scheme (301-redirecting /xui and /xui/API to /panel and /panel/api). That cutover was long ago, so drop the middleware, its registration in initRouter, and the now-inaccurate "URL redirection" mention in the middleware package doc. Old /xui URLs now 404 like any other unknown path. HTTPS auto-redirect and auth redirects are unrelated and stay. * build: fix .dockerignore for internal/ layout and exclude runtime dir - web/dist -> internal/web/dist: the embedded frontend moved under internal/, so the stale exclude no longer matched and the locally-built dist could be sent to the build context (the frontend stage rebuilds it fresh anyway). - exclude x-ui/: the local runtime directory (SQLite db, geo .dat files, xray binaries, certs — ~150MB) was being shipped into the build context for no reason. Verified the pattern excludes only the directory and still keeps x-ui.sh, which the Dockerfile copies to /usr/bin/x-ui.	2026-06-10 15:19:22 +02:00