From adca6e0f64e13501451f62a18d19efbba4924d13 Mon Sep 17 00:00:00 2001 From: Marco Date: Wed, 22 Jul 2026 07:31:02 +0000 Subject: [PATCH] Fix verify-email redirect pointing at the internal container address MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit request.url reflects the container's internal 0.0.0.0:3000 behind Caddy's reverse proxy, not the public domain — sent real browsers to an unreachable address. Caught live during post-deploy verification. Co-Authored-By: Claude Sonnet 5 --- app/api/account/verify-email/route.ts | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/app/api/account/verify-email/route.ts b/app/api/account/verify-email/route.ts index e83e320..eb45a5f 100644 --- a/app/api/account/verify-email/route.ts +++ b/app/api/account/verify-email/route.ts @@ -4,12 +4,20 @@ import { verifyEmailByToken } from "../../../lib/customerAuth"; // Entered from the link in the verification email — no session exists // yet at this point. See Customers.ts's own comment on why this is a // non-blocking flag (login already works before this is ever clicked). +// +// Base URL is deliberately NOT built from request.url — behind Caddy's +// reverse proxy that reflects the container's internal address +// (0.0.0.0:3000, confirmed live), not the public domain, and would send a +// real browser to an unreachable address. Same hardcoded-origin approach +// as Customers.ts's own FRONTEND_URL default on the Payload side. +const SITE_URL = "https://einfach-produktiv.mk360.de"; + export async function GET(request: NextRequest) { const token = request.nextUrl.searchParams.get("token"); if (!token) return new Response("Ungültiger Link.", { status: 400 }); const ok = await verifyEmailByToken(token); - const url = new URL("/konto/profil", request.url); + const url = new URL("/konto/profil", SITE_URL); url.searchParams.set("verified", ok ? "1" : "0"); return NextResponse.redirect(url); }