gitea
caf4fd80d1
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>
92 lines
4.0 KiB
Markdown
92 lines
4.0 KiB
Markdown
# astroklient — wersja demonstracyjna (PRE-28)
|
|
|
|
Osobna warstwa prezentacji o **dwóch funkcjach**:
|
|
|
|
1. **dodanie pliku bazy** — wgranie i włączenie do użytku jedną czynnością,
|
|
2. **zapytanie o interpretację urodzeniową** dla podanych danych wejściowych.
|
|
|
|
I na tym koniec. Nie ma tu kosmogramu, synastrii, kalendarza, promptów do modelu,
|
|
eksportu ani kont — nie są ukryte, tylko **nie istnieją w tym obrazie**.
|
|
|
|
## Dlaczego osobna usługa, a nie konto z ograniczeniami
|
|
|
|
Mechanizm uprawnień z PRE-27 umiałby to ukryć w pełnej aplikacji. Ale **ukrycie
|
|
a nieobecność to dwie różne rzeczy**: tutaj nie ma tras, nie ma szablonów, nie ma
|
|
nawet metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy
|
|
okazji kodu reszty programu.
|
|
|
|
## Izolacja: własne dane, pula na konto
|
|
|
|
```
|
|
astroklient → logic-demo → data-demo → udział astrololo-demo (pusty na starcie)
|
|
└── klientA/ ← pula konta
|
|
└── klientB/ ← pula konta
|
|
```
|
|
|
|
**Oryginalne bazy interpretacyjne są dla demo nieosiągalne.** Nie chodzi
|
|
o uprawnienia: demo ma własną warstwę danych, pracującą na osobnym udziale.
|
|
Osobna jest też warstwa logiczna, bo zna ona JEDEN adres warstwy danych — demo
|
|
korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.
|
|
|
|
**Każde konto ma własną pulę** plików: swój podkatalog na tym udziale. Konta nie
|
|
widzą swoich baz nawzajem ani w liście, ani w wynikach wyszukiwania. Dlatego demo
|
|
można rozdawać szeroko.
|
|
|
|
Pula bierze się **z loginu zalogowanej osoby** i z niczego innego. Gdyby
|
|
przychodziła z żądania, wystarczyłoby podstawić cudzy login, żeby czytać cudze
|
|
bazy — osobny test wysyła `tenant`, `user` i `login` w formularzu i sprawdza, że
|
|
nie mają na nią wpływu.
|
|
|
|
Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
|
|
w nazwie katalogu: `../..` czy ukośnik wyprowadziłyby zapytanie poza udział.
|
|
|
|
**Pula klienta to jeden katalog**, więc przejście na pełną wersję nie oznacza
|
|
utraty wgrań — procedura importu jest w runbooku wdrożenia (repo `deploy`,
|
|
`astrololo/README-astroklient.md`).
|
|
|
|
## Konfiguracja
|
|
|
|
| zmienna | znaczenie |
|
|
|---|---|
|
|
| `LOGIC_URL` | adres warstwy logicznej (domyślnie `http://localhost:8001`) |
|
|
| `DEMO_USERS` | konta jako `login:sekret`, po przecinku. Sekret jawny albo hash `scrypt$sól$hash`. Każdy login = osobna pula plików |
|
|
| `DEMO_USER` / `DEMO_PASSWORD` | pojedyncze konto — zgodność wstecz, działa gdy `DEMO_USERS` jest puste. **Brak obu = aplikacja stoi otwarta** i mówi o tym głośno przy starcie |
|
|
| `INTERNAL_TOKEN` | token międzywarstwowy (LOG-32) — ten sam co reszta usług |
|
|
| `LINK_KEY_PRESENTATION_LOGIC` | klucz szyfrowanego łącza (PRE-16) — ten sam co prezentacja |
|
|
| `RATE_LIMIT_PER_MIN` | limit żądań na adres, domyślnie 60; `0` wyłącza |
|
|
| `REPORT_LIMIT` | górny limit rekordów w jednej odpowiedzi, domyślnie 2000 |
|
|
| `TRUST_PROXY` | `true` za Ingressem — inaczej limit liczy wszystkich do jednego wiadra |
|
|
|
|
Hash hasła zrobisz tym samym skryptem, co dla głównej aplikacji:
|
|
|
|
```bash
|
|
cd services/presentation && python scripts/make_user.py demo
|
|
```
|
|
|
|
## Uruchomienie lokalne
|
|
|
|
```bash
|
|
cd services/astroklient
|
|
pip install -r requirements-dev.txt
|
|
DEMO_PASSWORD=tajne LOGIC_URL=http://localhost:8001 \
|
|
uvicorn app.main:app --port 8005
|
|
```
|
|
|
|
Testy:
|
|
|
|
```bash
|
|
cd services/astroklient && PYTHONPATH=. pytest tests -q
|
|
```
|
|
|
|
## Co pilnują testy
|
|
|
|
Poza zwykłą poprawnością — dwie własności, które łatwo zepsuć bez zauważenia:
|
|
|
|
* **powierzchnia**: zbiór tras aplikacji musi być dokładnie taki, jak dwie funkcje
|
|
wymagają; klient warstwy logicznej ma tylko te metody, których używa. Trasa,
|
|
o której nikt nie pamiętał, jest tu realnym ryzykiem, bo ta usługa rozmawia
|
|
z produkcyjną warstwą danych.
|
|
* **milczenie o regułach walidacji**: plik odrzucony daje komunikat bez powodu.
|
|
Reguły zna wyłącznie administrator w pełnej aplikacji (DAN-27), a demo nie ma
|
|
prawa ich zdradzić nawet mimochodem.
|