Demo ma być rozdawane szeroko i różnym osobom, więc pierwsza wersja — jedno konto
na produkcyjnej warstwie danych — nie nadawała się do użycia: każdy dostawałby
dostęp do oryginalnych baz, a wgrania jednego klienta widzieliby wszyscy.
IZOLACJA OD PRODUKCJI. Warstwa danych i logiczna demo są osobne (manifesty w repo
deploy). Osobna musi być TEŻ LOGICZNA, bo zna ona jeden adres warstwy danych —
demo korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.
PULE PER KONTO w warstwie danych. Zapytanie i lista plików niosą nazwę puli;
puste = cały udział, czyli produkcja działa dokładnie jak dotąd i o pulach nic
nie wie. Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
w nazwie katalogu — „../..” albo ukośnik wyprowadziłyby zapytanie wprost do cudzych
baz, więc sito ZAMIENIA podejrzane znaki zamiast ufać, że nikt ich nie poda.
PULA MUSI BYĆ W KLUCZU CACHE ZAPYTAŃ. Bez tego wynik policzony dla jednego konta
trafiłby z cache do drugiego — cicha wymiana treści baz między klientami,
niewidoczna w logach i nie do wykrycia z zewnątrz. Osobny test tego pilnuje.
PULA WYNIKA Z LOGINU, nigdy z żądania. Klient warstwy logicznej jest budowany
per żądanie i związany z pulą zalogowanej osoby; gdyby nazwa przychodziła
z formularza, wystarczyłoby podstawić cudzy login. Test wysyła `tenant`, `user`
i `login` w polach formularza i sprawdza, że nie mają na nią wpływu.
Pulę wstrzykujemy w INSTANCJĘ klienta, nie w sygnatury metod. Argumentem trzeba
by ją przeprowadzić przez protokół DataSource i build_report — kod, który o kontach
nie ma prawa nic wiedzieć — a każde nowe wywołanie byłoby okazją, żeby o nią
zapomnieć i sięgnąć nie tam.
Konta demo to lista `login:sekret` (DEMO_USERS), bo jedno wspólne konto oznaczałoby
wspólną pulę. Format i skrypt haseł te same, co w głównej aplikacji.
Pula klienta to JEDEN KATALOG, więc przejście na pełną wersję nie oznacza utraty
wgrań — procedurę importu opisuje runbook w repo deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Po wdrożeniu DAN-27 przestało działać wyszukiwanie (500 z /search) i ekran
Ustawienia (502 z /bases). Ekran „Pliki" działał, co dobrze pokazuje, gdzie leżał
problem: nie w rejestrze, tylko w JEGO STYKU z kodem, który zastąpił.
1. NameError przy KAŻDYM wyszukiwaniu. Przepisując `_enabled_files` pod rejestr
usunąłem lokalny `from app import bases`, a modułowego w tym pliku nigdy nie
było. Wołanie bases.disabled_entries() wywracało się natychmiast.
2. KeyError na /bases. Rejestr oddawał `in_use`, a endpoint liczy `b["enabled"]` —
tak samo warstwa logiczna i szablon Ustawień (DAN-15/PRE-09). Rejestr wszedł
w miejsce starej listy baz, więc musi mówić jej językiem; oddaje teraz oba
pola o tej samej wartości.
3. Cache podawany jako baza. `_scan` filtrował tylko nazwę PLIKU, więc zawartość
`.cache` wchodziła do rejestru (pliki w środku nie zaczynają się od kropki),
a przy pierwszym uruchomieniu była jeszcze przyjmowana jako aktywna. Teraz
pomijamy wszystko, co leży w ukrytym KATALOGU. Ten wyszedł dopiero z nowych
testów — nie wiedziałem o nim.
DLACZEGO TESTY TEGO NIE ZŁAPAŁY. test_files.py sprawdza rejestr w IZOLACJI i był
zielony, podczas gdy produkcja leżała. Groźne w takiej podmianie nie jest to, co
nowy moduł robi w środku, tylko czy mówi tym samym językiem, co jego odbiorcy.
Doszedł więc test_rejestr_integracja.py: wyszukiwanie przez dostawcę (obie gałęzie,
także ta z DISABLED_BASES), kontrakt pól listy baz, endpoint /bases przez trasę
oraz odstawienie bazy widziane JEDNOCZEŚNIE w wyszukiwaniu i w liczniku.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea