Timo Knuth
113acc073f
Groundwork for testmodul.qrmaster.net, a second stack running the `test` branch on a real qrmaster.net subdomain. Production scopes its session cookie to .qrmaster.net, so the browser sends it to every subdomain including staging. With both environments naming the cookie `userId`, the browser holds two cookies of the same name and cookies.get() picks one arbitrarily - staging logins would look randomly signed-out. AUTH_COOKIE_NAME lets staging pick `userId_test` instead. Production keeps the `userId` default; changing it there would invalidate every existing session. Wired getAuthCookieName() into the six places that named the cookie literally. The account deletion route now expires both the host-only and the domain-scoped variant like the logout route already does, instead of a single cookies().delete() that would leave the other one behind. NEXT_PUBLIC_WWW_URL and NEXT_PUBLIC_APP_URL become build ARGs so the same image can be built pointing at the staging host - the defaults keep a plain production build byte identical to before. Like COOKIE_DOMAIN these must exist at build time, because process.env is inlined into the Edge middleware bundle. robots.ts now serves Disallow-all unless NEXT_PUBLIC_INDEXABLE is true. Staging otherwise returns the production robots.txt and invites crawlers to index a duplicate of www. docker-compose.test.yml is the staging overlay. Two things it must get right, both verified against `docker compose config`: - db and redis need `networks: !override`. Compose MERGES the networks mapping from the base file, and since qrmaster-network is external and shared, a plain list left them attached to it - `db` would then resolve to two containers and staging could read and write the production database. - The web entrypoint is replaced so `prisma migrate deploy` never runs. prisma/migrations stopped in April 2026 and the schema has moved on through manual SQL since, so applying them to a fresh database would build a stale schema. Staging gets its schema from `pg_dump --schema-only` against production instead. Verified: tsc clean, production build succeeds, and the merged compose config confirms staging keeps db/redis off the shared network while production resolves unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
91 lines
3.0 KiB
TypeScript
91 lines
3.0 KiB
TypeScript
import { NextRequest, NextResponse } from 'next/server';
|
|
import { appendExpiredCookies, getAuthCookieName } from '@/lib/cookieConfig';
|
|
import { getSessionUserId } from '@/lib/session';
|
|
import { db } from '@/lib/db';
|
|
import { stripe } from '@/lib/stripe';
|
|
import { csrfProtection } from '@/lib/csrf';
|
|
import { rateLimit, getClientIdentifier, RateLimits } from '@/lib/rateLimit';
|
|
|
|
export async function DELETE(request: NextRequest) {
|
|
try {
|
|
// CSRF Protection
|
|
const csrfCheck = csrfProtection(request);
|
|
if (!csrfCheck.valid) {
|
|
return NextResponse.json(
|
|
{ error: csrfCheck.error },
|
|
{ status: 403 }
|
|
);
|
|
}
|
|
|
|
const userId = getSessionUserId();
|
|
|
|
// Rate Limiting (user-based)
|
|
const clientId = userId || getClientIdentifier(request);
|
|
const rateLimitResult = rateLimit(clientId, RateLimits.ACCOUNT_DELETE);
|
|
|
|
if (!rateLimitResult.success) {
|
|
return NextResponse.json(
|
|
{
|
|
error: 'Too many requests. Please try again later.',
|
|
retryAfter: Math.ceil((rateLimitResult.reset - Date.now()) / 1000)
|
|
},
|
|
{
|
|
status: 429,
|
|
headers: {
|
|
'X-RateLimit-Limit': rateLimitResult.limit.toString(),
|
|
'X-RateLimit-Remaining': rateLimitResult.remaining.toString(),
|
|
'X-RateLimit-Reset': rateLimitResult.reset.toString(),
|
|
}
|
|
}
|
|
);
|
|
}
|
|
if (!userId) {
|
|
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
|
|
}
|
|
|
|
// Get user data including Stripe information
|
|
const user = await db.user.findUnique({
|
|
where: { id: userId },
|
|
select: {
|
|
id: true,
|
|
stripeSubscriptionId: true,
|
|
stripeCustomerId: true,
|
|
plan: true,
|
|
},
|
|
});
|
|
|
|
if (!user) {
|
|
return NextResponse.json({ error: 'User not found' }, { status: 404 });
|
|
}
|
|
|
|
// Cancel Stripe subscription if user has one
|
|
if (user.stripeSubscriptionId && user.plan !== 'FREE') {
|
|
try {
|
|
await stripe.subscriptions.cancel(user.stripeSubscriptionId);
|
|
} catch (stripeError) {
|
|
console.error('Error canceling Stripe subscription:', stripeError);
|
|
// Continue with deletion even if Stripe cancellation fails
|
|
}
|
|
}
|
|
|
|
// Delete user and all related data (cascading deletes should handle QR codes, scans, etc.)
|
|
await db.user.delete({
|
|
where: { id: userId },
|
|
});
|
|
|
|
// Clear auth cookie. Same reasoning as the logout route: both the host-only and the
|
|
// domain-scoped variant have to be expired, otherwise the survivor keeps a session
|
|
// pointing at a user row that no longer exists.
|
|
const response = NextResponse.json({ success: true });
|
|
appendExpiredCookies(response.headers, [{ name: getAuthCookieName(), httpOnly: true }]);
|
|
|
|
return response;
|
|
} catch (error) {
|
|
console.error('Error deleting account:', error);
|
|
return NextResponse.json(
|
|
{ error: 'Internal server error' },
|
|
{ status: 500 }
|
|
);
|
|
}
|
|
}
|