Verwaltungsseite: kein separater dritter Code mehr, sondern derselbe wie beim normalen Login

Fix für gemeldetes Problem: VanVans Code funktionierte nicht auf der Verwaltungsseite. Ursache
war ein dritter, komplett separater, gemeinsamer Code (6GAM4AST), den sich niemand gemerkt
hatte — VanVan gab stattdessen ihren normalen persönlichen Zugangscode ein, der dort aber nicht
galt. Jetzt auf ausdrücklichen Wunsch vereinheitlicht: die Verwaltungsseite prüft denselben
persönlichen Code wie der normale Seitenzugang (SITE_ACCESS_CODE_QCIGA/_VANVAN). Die tägliche
Neueingabe-Pflicht bleibt bestehen (eigene Sitzung mit 24h statt 90 Tagen Gültigkeit) — nur der
geprüfte Code ist jetzt kein separater dritter mehr. Das alte Secret VERWALTUNG_ACCESS_CODE wird
nicht mehr verwendet. Lokal mit wrangler pages dev end-to-end getestet (beide Codes + alter Code
korrekt abgelehnt).

Co-Authored-By: Claude Sonnet 5 <[email protected]>

functions/_middleware.js

@@ -31,11 +31,13 @@
      ist nie für Kund:innen gedacht. /api/orders (Bestellung ANLEGEN beim Checkout) ist bewusst
      NICHT dauerhaft geschützt — das muss auch für echte Kund:innen erreichbar sein, sobald der
      Shop öffentlich ist, genau wie der Checkout selbst.
-   - /verwaltung/* + /api/verwaltung/* verlangen ZUSÄTZLICH zum normalen 90-Tage-Seitenzugang
-     noch einen zweiten, eigenen, FESTEN Code (siehe functions/_shared/verwaltung-auth.js,
-     /verwaltung-code.html) — auf ausdrücklichen Wunsch. Der Code selbst ändert sich NICHT von
-     selbst (kein Zufalls-/Rotationscode) — nur die SITZUNG läuft nach 24 Stunden ab, wodurch
-     derselbe Code einmal täglich neu eingegeben werden muss, statt für immer gültig zu bleiben.
+   - /verwaltung/* + /api/verwaltung/* verlangen ZUSÄTZLICH zum normalen 90-Tage-Seitenzugang noch
+     eine zweite, eigene Sitzung, die nur 24 Stunden gültig ist (siehe
+     functions/_shared/verwaltung-auth.js, /verwaltung-code.html) — auf ausdrücklichen Wunsch.
+     Geprüft wird dabei GENAU DERSELBE persönliche Code wie beim normalen Seitenzugang (kein
+     separater dritter Code mehr — das hatte anfangs zu Verwirrung geführt, siehe Tagesprotokoll
+     04.08.2026). Wer /verwaltung/ öffnen will, tippt also überall denselben Code, muss ihn aber
+     hier einmal täglich neu eingeben, statt 90 Tage lang eingeloggt zu bleiben.
    - API-Routen (/api/*) bekommen bei fehlender Sitzung eine 401-JSON-Antwort statt der
      302-Weiterleitung zur Zugangscode-Seite — ein fetch() im Checkout/Verwaltung-Skript soll
      einen klaren Fehler sehen, nicht versehentlich HTML als Antwort bekommen.
@@ -109,11 +111,14 @@ async function handleAuth(request, env) {
   return new Response(JSON.stringify({ ok: true, next }), { status: 200, headers });
 }
 
-/* Gegenstück zu handleAuth() oben, aber für den zweiten, verwaltungseigenen Code — bewusst EIN
-   gemeinsamer, FESTER Code (kein Unterschied qciga/VanVan, keine Rotation), da es hier nur um
-   die zusätzliche Hürde geht, nicht um eine rollenabhängige Anzeige. Nur die dadurch erzeugte
-   SITZUNG läuft nach 24h ab (siehe VERWALTUNG_SESSION_STUNDEN unten) — der Code selbst bleibt
-   unverändert, bis ihn qciga manuell über "wrangler pages secret put" ändert. */
+/* Gegenstück zu handleAuth() oben, aber für die zweite, tägliche Sitzung auf /verwaltung/ — auf
+   ausdrücklichen Wunsch NACH einer Verwirrung mit einem anfangs dritten, separaten Code umgestellt
+   (04.08.2026): Es gibt KEINEN eigenen Verwaltungs-Code mehr. Stattdessen gilt hier genau derselbe
+   persönliche Code wie beim normalen Seitenzugang (SITE_ACCESS_CODE_QCIGA / SITE_ACCESS_CODE_VANVAN,
+   siehe handleAuth() oben) — wer sich einmal am Tag einloggt, tippt also überall denselben, ihr
+   bereits bekannten Code, statt sich einen dritten, separaten Code merken zu müssen. Einzige
+   Besonderheit gegenüber dem normalen Zugang: die dadurch erzeugte SITZUNG läuft schon nach 24h ab
+   (statt 90 Tage), wodurch derselbe Code hier täglich neu eingegeben werden muss. */
 async function handleVerwaltungAuth(request, env) {
   let body;
   try {
@@ -127,7 +132,10 @@ async function handleVerwaltungAuth(request, env) {
   const code = (body.code || "").trim();
   const next = typeof body.next === "string" && body.next.startsWith("/") ? body.next : "/verwaltung/";
 
-  if (!env.VERWALTUNG_ACCESS_CODE || code !== env.VERWALTUNG_ACCESS_CODE) {
+  const codeGueltig =
+    (env.SITE_ACCESS_CODE_QCIGA && code === env.SITE_ACCESS_CODE_QCIGA) ||
+    (env.SITE_ACCESS_CODE_VANVAN && code === env.SITE_ACCESS_CODE_VANVAN);
+  if (!codeGueltig) {
     return new Response(JSON.stringify({ ok: false, error: "Falscher Code." }), {
       status: 401,
       headers: { "Content-Type": "application/json" },
@@ -206,10 +214,12 @@ export async function onRequest(context) {
       return handleVerwaltungAuth(request, env);
     }
 
-    // Fail-open auch hier: fehlt das Secret komplett, lieber die zweite Schranke nicht scharf
-    // schalten, als sich selbst auszusperren — die erste Schranke (normaler Seitenzugang)
-    // schützt /verwaltung/ in diesem Fall ja immer noch.
-    if (!env.VERWALTUNG_SESSION_SECRET || !env.VERWALTUNG_ACCESS_CODE) {
+    // Fail-open auch hier: fehlt das Sitzungs-Secret komplett, lieber die zweite Schranke nicht
+    // scharf schalten, als sich selbst auszusperren — die erste Schranke (normaler Seitenzugang)
+    // schützt /verwaltung/ in diesem Fall ja immer noch. Die Zugangscodes selbst
+    // (SITE_ACCESS_CODE_QCIGA/_VANVAN) sind an dieser Stelle bereits garantiert vorhanden, siehe
+    // codesKonfiguriert-Prüfung weiter oben in onRequest().
+    if (!env.VERWALTUNG_SESSION_SECRET) {
       return next();
     }