Fresh Docker installs created the admin as admin@sub2api.local and accepted
any ADMIN_PASSWORD (e.g. "123456"), making them easy brute-force targets.
- Generate a random admin-<12 hex>@sub2api.local login email when
ADMIN_EMAIL is empty; drop the fixed default from .env.example and the
compose files, and have docker-deploy.sh write a random ADMIN_EMAIL.
- Validate user-supplied ADMIN_PASSWORD (8-72 bytes) and ADMIN_EMAIL on the
auto-setup path, only when an admin is actually about to be created, so
existing deployments are never blocked at startup.
- Align validateEmail with the login endpoint's email binding so setup can no
longer create an admin that can never log in (e.g. "a@b", "Name <a@b.com>").
- Cap validatePassword at bcrypt's 72-byte limit; the CLI reuses it and now
defaults to a random admin email instead of admin@example.com.
- Update READMEs/deploy docs to stop suggesting guessable credentials.
The star history chart was broken due to GitHub stargazer API restrictions. Update the chart URLs in README.md, README_CN.md and README_JA.md so the chart renders again.
PR #1463 removed the Sora platform, but some references survived:
- README/README_CN/README_JA kept the 'Sora status (temporarily
unavailable)' sections and gateway.sora_* docs that the removal PR
never touched.
- deploy/config.example.yaml still documented ~130 lines of sora_*
gateway keys, the top-level sora: direct-client/storage block, and
token_refresh.sync_linked_sora_accounts - none of which map to any
field in the config structs anymore.
- The OIDC login PR (02a66a01c, branched off pre-removal main and
merged 4 days after #1463) re-added the dead
PublicSettings.SoraClientEnabled field, which no code ever sets.
- A release sync (748a84d87) re-introduced sora i18n keys that the
later i18n split (d9e514f98) faithfully carried into
locales/{zh,en}/admin/{overview,settings}.ts. No component references
any of these keys.
This drops all of the above. Pure deletions, no behavior change.
DEV_GUIDE.md and the three READMEs still advertise Go 1.25.7 and
golangci-lint v2.7, but CI has since moved on:
- backend/go.mod declares go 1.26.5, and backend-ci.yml / release.yml /
security-scan.yml all resolve the toolchain via
`go-version-file: backend/go.mod` and then hard-assert
`go version | grep -q 'go1.26.5'`.
- backend-ci.yml pins golangci-lint to v2.9.
So a contributor following DEV_GUIDE.md installs a linter two minor
versions behind CI (different findings locally vs. in CI) and expects a
Go version that the workflow's own assertion step rejects.
Update all ten stale references, and note in the CI section which files
the Go version assertion lives in so future bumps don't miss one.
Docs only, no code or workflow changes.
`cli-chat-proxy.grok.com` turns away requests that do not name a
supported client version — the failure mode #3952 was opened for. The
pin has sat at 0.2.93 since 2026-07-17, while https://x.ai/cli/stable
and `npm view @xai-official/grok version` both report 0.2.114.
The version was written out in three places, which is how they came to
drift:
- `repository/http_upstream.go` (OAuth traffic through the CLI proxy)
- `pkg/xai/billing.go` (billing and quota probes)
- `service/openai_gateway_grok.go` (gateway request headers)
`xai.CLIClientVersion` is now the single source, and the other two build
their own client identity from it, so the next bump is one line.
`internal/pkg/xai` is a leaf package both layers already import, so this
adds no cycle. `CLIUserAgent` derives from the same constant.
Checked against the real 0.2.114 binary rather than the version feed
alone: the `x-grok-client-version` header name, the `xai-grok-cli`
token-auth value, and the version string all match what the CLI sends.
The pinned value is also the floor an operator override must clear, so
some fixtures carried a meaning relative to it rather than a fixed
number. Those were moved, not search-and-replaced:
- the "valid override" case now uses 0.2.115-alpha.1; at 0.2.95-alpha.1
it would fall below the new floor, be dropped, and stop testing
acceptance at all
- the prerelease-at-the-minimum case tracks the pin to 0.2.114-beta.1,
or it becomes a copy of the below-minimum case
- three of the five malformed-semver entries sat below the new floor and
would have been turned away for being old, not for being malformed
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
shaw