gitea
d3d9b365fe
build / build (push) Successful in 17s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m29s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 11s
Testy / Kontrola składni wszystkich warstw (push) Successful in 8s
Jedno wspólne hasło nie mówiło, KTO sięgał do baz, a odebranie dostępu jednej osobie wymagało zmiany hasła wszystkim. Przy bazach o realnej wartości handlowej to za mało. KONTA IMIENNE: `APP_USERS='alicja:scrypt$…,bartek:scrypt$…'`. Hash liczy scrypt ze STDLIB — zero nowych zależności; hasła nie ma w konfiguracji jawnie. Zakładanie konta: scripts/make_user.py (hasło interaktywnie, nie w historii powłoki). Odebranie dostępu = usunięcie wpisu, reszta nie zmienia haseł. Gdy APP_USERS jest ustawione, wspólne APP_PASSWORD PRZESTAJE działać (ostrzeżenie przy starcie) — działające obok kont byłoby tylnym wejściem bez śladu w dzienniku. Dopóki APP_USERS nie jest ustawione, stary tryb działa jak dotąd (zgodność wstecz). DZIENNIK AUDYTOWY: każde żądanie zostawia wpis „kto, skąd, co, status, ILE rekordów, ile ms". Liczba rekordów jest tu sednem — pojedyncze zapytanie wygląda niewinnie, suma pokazuje powolne wypompowywanie bazy przez osobę uprawnioną. Liczona dla wyszukiwarki sygnifikatorów, raportu i eksportu do Excela (ten wynosi najwięcej naraz). W logach NIE MA treści — ani rekordów, ani promptów. Dwa realne błędy złapane po drodze: - `secrets.compare_digest` rzuca TypeError na znakach spoza ASCII, więc hasło z polskimi literami wywracało logowanie błędem 500 zamiast odmowy (błąd ZASTANY, sprzed tej zmiany) — porównujemy teraz bajty; - dziennik był PUSTY na żywym serwerze: domyślna konfiguracja uvicorna nie obsługuje naszych loggerów. Niewidoczny dziennik jest gorszy niż jego brak, więc audyt dostał własny handler na stdout. Oba przypadki mają testy regresji. Instrukcja wdrożeniowa: docs/konta-i-audyt.md. Testy: +15. Prezentacja 243. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Warstwa prezentacji (presentation)
Niezależna usługa serwująca stronę WWW (formularz + tabela wyników). W dół przekazuje dane z formularza do warstwy logicznej i renderuje opracowane wyniki. Brak logiki biznesowej i dostępu do danych.
Trasy
GET /— Horoskop: formularz danych momentu (data, godzina, strefa, opcjonalnie lokalizacja)POST /— liczy pozycje obiektów (woła logic/chart/positions) i renderuje czytelną tabelęGET /significators,POST /significators— wyszukiwarka w bazach interpretacji (warstwa danych)GET /health
Strona „Horoskop" to widok do ręcznego testowania: podstawowe dane wejściowe → to, co policzyła warstwa logiczna (znak, pozycja w znaku, absolutna, kierunek, prędkość). Przycisk „Tu i teraz" uzupełnia bieżącą datę/godzinę i strefę przeglądarki.
Zależności w dół
Zna wyłącznie LOGIC_URL (adres warstwy logicznej) i jej kontrakty /chart/positions
oraz /api/query. Nie wie nic o silniku ani bazach.
Uwaga: pełne liczenie pozycji wymaga warstwy logicznej z silnikiem efemeryd (gałąź
feat/logic-engine). Bez niego strona „Horoskop" pokaże czytelny komunikat.
Uruchomienie
pip install -r requirements.txt
export LOGIC_URL=http://localhost:8001
uvicorn app.main:app --port 8000
# otwórz http://localhost:8000