Nick SzaunigandClaude Sonnet 5
1e53758753
Der voran gegangene Fix (proxy.ts nach src/ verschoben, damit Next.js sie ueberhaupt erkennt) hat eine zweite, bislang tote Stelle live geschaltet: eine Cookie-Pruefung auf "refreshToken", die zu /login umleitet, wenn das Cookie fehlt - fuer /settings, /apiaries, /colonies, /queens. Dieses Cookie wird vom BACKEND gesetzt (eigene Domain, apicorebackend.* statt apicore.*, Pfad /api/v1/auth) und ist dem Browser zufolge nie Teil einer Anfrage an das Frontend - proxy.ts lief auf der Frontend-Domain und konnte dieses Cookie strukturell nie sehen. Solange die Datei am falschen Ort lag und nie ausgefuehrt wurde, blieb das folgenlos; sobald sie lief, hat sie jeden Aufruf dieser Seiten serverseitig zurueck zu /login geschickt, unabhaengig vom tatsaechlichen Login-Status. Die Cookie-Pruefung komplett entfernt statt repariert: es gibt keinen Weg, ein cross-origin gesetztes Cookie hier sichtbar zu machen, ohne seinen Schutz (Pfad-Scoping) aufzuweichen. Die echte Session lebt ohnehin nur clientseitig (Access-Token im Speicher, Refresh-Cookie nur fuer Backend-Aufrufe) - src/app/(app)/layout.tsx prueft das bereits korrekt und leitet bei Bedarf weiter. proxy.ts setzt jetzt nur noch die Security-Header. Lokal verifiziert: /settings/users ohne jedes Cookie liefert jetzt 200 statt eines Redirects, CSP zeigt weiterhin den korrekten Laufzeit-API_URL. Co-Authored-By: Claude Sonnet 5 <[email protected]>