v1.4.4

MirrorProxy 1.4.4

MirrorProxy 1.4.4 fixes remote HTTP browser sign-in for both Docker and binary
deployments, updates vulnerable dependencies, and makes the bilingual deployment
Wiki easier to follow. Thank you to @ignitiondl
for reporting Issue #10.

Browser sign-in over HTTP and HTTPS

Previously, the server could accept the correct password and return HTTP 200,
but a browser visiting a remote HTTP address rejected the Secure session cookie
and the __Host- CSRF cookie. Subsequent requests returned 401 and the console
returned to the sign-in form. This was a session transport issue, not rejection
of a weak initial environment password.

• HTTP password sign-in now uses separate HTTP session and CSRF cookie names.
• HTTPS retains Secure session cookies and the __Host- CSRF cookie. HTTP and
  HTTPS browser sessions are isolated; sign in again when switching protocols.
• A persistent English/Chinese warning on HTTP pages explains the exposure of
  passwords and sessions and links to the HTTPS deployment guide.
• HTTPS detection follows the native TLS listener or protocol headers from an
  explicitly trusted proxy, rather than assuming that a configured HTTPS public
  URL makes every connection secure.
• Same-origin, session-bound CSRF validation, session HttpOnly attributes,
  authorization, login rate limits, and lockout remain in place.

HTTP does not encrypt passwords or sessions. Use HTTPS for normal operation.
Passkeys and identity providers retain their existing secure-origin requirements.

The initial-password contract is unchanged: a non-empty
MIRRORPROXY_ADMIN_PASSWORD is used verbatim only when the database has no
administrators. Changing the variable on later starts does not overwrite the
stored password. Do not delete your database to resolve sign-in problems.

Dependency updates

• rustls 0.23.45 → 0.23.46 and quinn-proto 0.11.16 → 0.11.18 address
  dependency security findings.
• source-map-js 1.2.1 → 1.2.2 incorporates the frontend dependency update
  from PR #11.
• async-trait 0.1.91 → 0.1.92 fixes compatibility with strict Clippy on the
  current stable Rust toolchain.
• The existing RUSTSEC-2023-0071 exception is unchanged. Dependency audit
  warnings for yanked chacha20 0.10.1 and spin 0.9.8 remain; this release
  does not claim that all dependency warnings have been eliminated.

Deployment documentation

The English and Simplified Chinese Wiki now starts with a complete Docker/Caddy
quick start and straightforward binary download, checksum, and startup steps.
It includes Nginx/OpenResty, Caddy, Traefik, Apache, and HAProxy configurations
and Nginx Proxy Manager interface settings. Advanced systemd, certificate,
configuration, and release-maintenance material follows the basic setup.
Both READMEs also link to the Linux.do community.

Compatibility, upgrade, and rollback

• No SQLite schema migration or configuration change is required. Preserve the
  database, configuration, cache, GeoIP inputs, and encryption master key.
• Verify the release archive against SHA256SUMS, keep the previous binary,
  replace the server, and restart using your existing service configuration.
• Docker and binary distributions share the same fix. Existing HTTPS sessions
  retain their cookie format. HTTP users must sign in to create a new session.
• To roll back, restore the previous v1.4.3 binary or image with the same data
  and configuration; remote HTTP browser sign-in will again require HTTPS.
• Publishing this release does not replace any production installation.

Verification and delivery

Release validation covers locked Rust workspace tests and strict Clippy with
all features, frontend tests/build and browser E2E, real administrator API smoke,
and real Chromium HTTP/HTTPS login. Browser regression coverage checks a weak
initial environment password, password persistence across restarts, reload,
logout, CSRF rejection, warning visibility, and protocol isolation.

Wiki checks cover local links, bilingual configuration parity, structured
configuration and shell syntax, eight Compose examples, and real local HTTPS
forwarding through five reverse proxies, including encoded paths, query strings,
Host preservation, forwarded-header spoof rejection, and Git POST payloads.
Public certificate issuance and live production deployment are separate.

CI and CodeQL are checked for the exact release commit before tagging. The
release workflow supplies cross-platform clients, server archives, native Linux
packages, checksums, signed APT contents, and package-manager metadata. A
representative published artifact is downloaded and checked for its checksum
and binary version during release verification. Docker image publication runs
independently and may finish later.

Full comparison: v1.4.3...v1.4.4