mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-20 14:34:25 +00:00
c8abf6de74
# Which Problems Are Solved The login container can only serve HTTP. In deployments where a reverse proxy is not used, operators need the login container to terminate TLS itself. Closes #11473 # How the Problems Are Solved The container now supports optional HTTPS via three environment variables that match the pattern already used by the backend server: `ZITADEL_TLS_ENABLED`, `ZITADEL_TLS_CERTPATH`, and `ZITADEL_TLS_KEYPATH`. When `ZITADEL_TLS_ENABLED` is not set or set to `false`, behavior is identical to before. When set to `true`, the server reads the provided certificate and key files and serves HTTPS using the lower-level `getRequestHandlers` API from Next.js. The Docker healthcheck was updated to probe the correct scheme automatically based on the same environment variable. # Additional Changes Added a dockerized integration test that verifies both HTTP and HTTPS modes using testcontainers. # Additional Context The TLS path uses `getRequestHandlers` from `next/dist/server/lib/start-server` instead of `startServer` because the latter rejects self-signed certificates in production mode. This is the same internal API that `startServer` itself calls. --------- Co-authored-by: Copilot <[email protected]>
15 lines
457 B
TypeScript
15 lines
457 B
TypeScript
import tsconfigPaths from "vite-tsconfig-paths";
|
|
import { defineConfig } from "vitest/config";
|
|
|
|
export default defineConfig({
|
|
plugins: [tsconfigPaths()],
|
|
test: {
|
|
include: ["dockerized/**/*.test.ts"],
|
|
// Increased timeouts are intentional: Docker image build and container startup
|
|
// can be slow in CI and local environments, so we allow up to 3 minutes.
|
|
testTimeout: 180000,
|
|
hookTimeout: 180000,
|
|
fileParallelism: false,
|
|
},
|
|
});
|