2 Commits

Author	SHA1	Message	Date
gitea	f0d07ee8c3	feat(bezpieczeństwo): sesje logowania zamiast HTTP Basic (LOG-34) ... Basic nie miał wylogowania i nie dało się tego obejść: przeglądarka zapamiętuje hasło i dosyła je SAMA przy każdym żądaniu, więc serwer nie ma czego zapomnieć. Poprzednia próba (LOG-32) opierała się na nakłonieniu przeglądarki, żeby porzuciła zapamiętane dane — zachowaniu powszechnym, ale nigdzie nie zapisanym. Teraz to serwer decyduje, czy dana przeglądarka jest w środku, i może to cofnąć. TRZY POZIOMY UNIEWAŻNIENIA, celowo rozdzielone, bo każdy kosztuje co innego: 1. wylogowanie = skasowanie ciasteczka. Natychmiastowe, bez magazynu. 2. zmiana hasła albo skasowanie konta = odcisk poświadczenia wpisany w ciasteczko przestaje pasować. Dzieje się SAMO, bez pamiętania o tym. Bez tego odebranie komuś dostępu nie odbierałoby dostępu aż do wygaśnięcia. 3. „zamknij sesje" z ekranu kont = licznik pokolenia. Jedyny wymagający zapisu, więc jedyny opcjonalny: gdy licznika nie ma, poziomy 1 i 2 nadal działają. KONTO ADMINISTRACYJNE ODSEPAROWANE. Sprawdzane pierwsze i BEZ DOTYKANIA pliku kont, co daje dwie rzeczy naraz: konto z pliku o tym samym loginie nie przesłoni administratora, a administrator zaloguje się także wtedy, gdy plik jest uszkodzony — czyli w jedynej sytuacji, w której ktoś MUSI wejść, żeby to naprawić. Trzymanie jego stanu w tym samym pliku dawałoby zakleszczenie: nie da się naprawić, bo nie da się wejść. Jego odpowiednikiem „wyloguj zewsząd" jest zmiana APP_PASSWORD. KLUCZ WYMAGANY, FAIL-CLOSED. Usługa z kontami, ale bez klucza podpisu, nie odróżniłaby ważnej sesji od podrobionej, więc nie wstaje — i lepiej przy starcie niż przy pierwszym logowaniu człowieka. Losowanie klucza byłoby wygodne, ale wylogowywałoby wszystkich przy każdym restarcie poda: wygląda jak awaria i uczy ludzi ignorować ekran logowania. Ciasteczko HttpOnly (jeden wstrzyknięty skrypt inaczej wynosi sesję) i SameSite=Strict (obca strona nie zadziała w imieniu zalogowanego). Wylogowanie POST-em, nie odsyłaczem: pod adresem GET wystarczyłby obrazek na obcej stronie. Adres powrotu po zalogowaniu przechodzi przez sito — bez tego `?dokad=https://obcy` zamieniłby nasz ekran logowania w narzędzie do wyłudzania haseł. Kres bezczynności 8 h i twardy 30 dni. Znacznik aktywności odświeżany z progiem, inaczej Set-Cookie leciałby przy każdym obrazku i arkuszu stylów. Zdarzenia logowania w dzienniku (PRE-17). Nieudane próby są tam ważniejsze od udanych: pojedyncza nic nie znaczy, ale seria pod jednym adresem to jedyny widoczny ślad zgadywania haseł. Test pilnuje, że hasło tam nie trafia. Sprawdzone w przeglądarce: po zalogowaniu ciasteczko jest NIEWIDOCZNE dla JavaScriptu, a po wylogowaniu wejście na chronioną stronę ląduje na ekranie logowania — czyli dokładnie to, czego Basic nie potrafił. Testy: 21 na rdzeń podpisywania (w tym podrabianie ładunku, podpisu i klucza, ciasteczko z przyszłości, śmieci na wejściu), reszta przepisana z Basic na sesje. Prezentacja 338 zielonych. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 00:18:15 +02:00
gitea	6466ab89a9	feat(dane): interfejs zarządzania plikami baz — trzy poziomy dostępu (DAN-27) ... Ekran „Pliki" z trzema poziomami, wpiętymi w kontrolę dostępu z PRE-27: „files" widzi listę i KLIKANIEM decyduje, z których baz program korzysta, „files_input" dokłada wgrywanie i ARCHIWIZACJĘ, administrator kasowanie, przywracanie z archiwum i REGUŁY WALIDACJI. STAN JEST TERAZ TRWAŁY. DAN-15 trzymał go w zmiennej DISABLED_BASES, bo warstwa danych nie miała gdzie zapisywać — udział był montowany read-only. Skoro stan ma być klikany, musi przetrwać restart, więc udział jest zapisywalny, a stan leży w pliku obok baz (zapis atomowy: plik opisuje CAŁY zbiór, więc obcięcie w połowie skasowałoby wiedzę o wszystkich naraz). DISABLED_BASES zostaje jako awaryjne wyłączenie z konfiguracji i odsiewa DODATKOWO — nie odwrotnie, bo inaczej ktoś z dostępem do ekranu włączyłby bazę wyłączoną świadomie na poziomie wdrożenia. ARCHIWIZACJA NIE KASUJE. Plik zostaje na dysku, zamrożony, ze znacznikiem czasu; znika wyłącznie z użytku. To najdalej idąca operacja osoby wgrywającej dane — kasować może tylko administrator. Test sprawdza, że plik po archiwizacji nadal istnieje, bo to jest cała istota tej operacji. WALIDACJA JEST BRAMKĄ DO UŻYTKU, NIE FILTREM NA WEJŚCIU. Plik wgrany zostaje NIEZALEŻNIE od wyniku — nie tracimy niczego, co ktoś wgrał. Zmienia się tylko to, czy da się go włączyć. Sprawdzenie biegnie też w chwili włączania, nie tylko przy wgrywaniu: reguły mogą się zmienić po fakcie. O WALIDACJI WIE TYLKO ADMINISTRATOR. Pliki wstrzymane są odsiewane W WARSTWIE DANYCH przy for_admin=False, a nie ukrywane w szablonie — gdyby dochodziły do przeglądarki, wystarczyłby podgląd źródła, żeby poznać reguły. Odmowa włączenia wraca do konta bez uprawnień BEZ POWODU, bo powód zdradza regułę. Sekcja reguł nie trafia nawet do źródła strony. Test parametryzowany po obu niższych poziomach szuka w odpowiedzi śladów mechanizmu i wymaga, żeby żadnego nie było. Każdy plik ma policzony sha256 — tożsamość niezależna od nazwy. Wykorzystuje ją już odrzucanie duplikatów, a w kroku drugim posłuży do pilnowania zgodności lustra w SQL. Przy okazji naprawiony błąd, który dopiero co bym wprowadził: Path("") to Path("."), czyli wartość PRAWDZIWA, więc `Path(os.getenv(...)) or domyślna` zawsze wybierało pustą zmienną i zapisywało stan do katalogu bieżącego. Wymaga zapisywalnego udziału — osobny PR w repo deploy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 14:39:42 +02:00