659a1ee9ce9462712ad7aaeb066c0ecbba311465
Zwei Ursachen, die zusammenwirkten. 1. Nach einem Neuladen war die HERKUNFT des Schluessels vergessen. Der Code speicherte nur den Schluessel selbst, nicht ob er aus einer Codeeingabe oder aus dem Ausweis der Zugangswand stammt. 2. Weil die Herkunft fehlte, wurde vorsichtshalber 'code' angenommen. Als Vorsicht gedacht, mit unangenehmer Kehrseite: Ein Ausweis gilt nur 15 Minuten. Als 'code' behandelt wurde er nie erneuert -- nach einer Viertelstunde kam der erste 401, und man landete in der Codeeingabe, obwohl alles in Ordnung war. Der Schutz 'eine Code-Sitzung wird nie durch einen Ausweis ersetzt' war damit ab dem ersten Neuladen ohnehin wirkungslos. Die Herkunft steht jetzt neben dem Schluessel und ueberlebt ein Neuladen. Fehlt sie -- etwa aus einer aelteren Sitzung --, bleibt es bei der vorsichtigen Annahme 'code'. Das behebt die Haelfte des Problems. Die andere Haelfte ist eine Einstellung auf dem Server: Die beiden Dienste benutzen nicht dasselbe WEBDESIGN_API_SECRET, weshalb jeder Ausweis abgelehnt wird. Der Kommentar in server/.env.example sagt ausdruecklich, dass beide Werte exakt gleich sein muessen. Das kann nur Filipe angleichen -- /home/dogiintern/ ist fuer claudian gesperrt. Co-Authored-By: Claude Opus 5 <[email protected]>
Description
No description provided
725 MiB
Languages
JavaScript
77.7%
CSS
13.1%
HTML
9%
Shell
0.2%