astroklient-demo — wersja demonstracyjna z izolacją i pulami per konto (PRE-28/29) #74
Reference in New Issue
Block a user
Delete Branch "feat/astroklient"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Osobna warstwa prezentacji: dodanie pliku bazy i zapytanie o interpretację urodzeniową. Nic więcej.
Osobna usługa, 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 pozostałych funkcji nie ma w obrazie: brak tras, brak szablonów, brak nawet metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy okazji kodu reszty programu.
Test porównuje zbiór tras aplikacji i zbiór metod klienta z listą dokładną, więc dopisanie czegokolwiek zapala się od razu:
Wgranie i włączenie to jedna czynność
W pełnej aplikacji to dwie osobne decyzje (DAN-27), bo tam ktoś nad tym panuje. Tutaj „dodać plik do bazy" musi znaczyć, że plik od razu bierze udział w wyszukiwaniu — inaczej po wgraniu nic by się nie zmieniło i demo wyglądałoby na zepsute.
Walidacja zostaje: plik o złym układzie nie wchodzi do użytku, ale nie jest tracony, a komunikat nie zdradza reguł — te zna wyłącznie administrator. Osobny test szuka w komunikacie śladów mechanizmu (
walidacj,reguł,kolumn,rozszerzeni,rozmiar).⚠️ Demo pracuje na produkcyjnej warstwie danych
Twoja świadoma decyzja, ale zapisuję ją wprost w README usługi i w manifeście, nie tylko w rozmowie:
Dlatego konto jest osobne (
DEMO_USER/DEMO_PASSWORD): demo odcina się skasowaniem jednego sekretu, bez ruszania kont głównej aplikacji.Rozmowa z warstwą logiczną idzie tym samym szyfrowanym łączem (PRE-16) i pod tym samym tokenem (LOG-32) — demo nie jest furtką omijającą ochronę. Automatyczna dokumentacja wyłączona, jak w pełnej aplikacji.
Drobiazgi
Zależności celowo krótsze niż w prezentacji: bez Excela, bez stref czasowych z lokalizacji, bez niczego pod kosmogram. Osobny job w CI. Obraz dołącza do tej samej pętli budowania, bo dzieli warstwę logiczną i musi powstawać z tego samego commita.
Weryfikacja
14 testów astroklienta; reszta bez zmian: prezentacja 303, logika 342, dane 37, render 41.
Idzie w parze z
deploy→feat/astroklient(manifest + runbook + wpis w image-updaterze).🤖 Generated with Claude Code
astroklient — wersja demonstracyjna o dwóch funkcjach (PRE-28)to astroklient-demo — wersja demonstracyjna z izolacją i pulami per konto (PRE-28/29)Demo idzie szeroko i do różnych osób, często na cudzych komputerach — więc wyjście z aplikacji jest tu potrzebne bardziej niż w pełnej wersji, a Basic go nie miał: przeglądarka zapamiętuje hasło i dosyła je sama przy każdym żądaniu. Pierwszy klient zostawiał otwartą sesję drugiemu. Ta sama konstrukcja co w pełnej aplikacji: własny ekran logowania, podpisane ciasteczko (HMAC-SHA256), HttpOnly + SameSite=Strict, wylogowanie POST-em, kres bezczynności i twardy, sito na adres powrotu, zdarzenia w dzienniku bez haseł. Moduł session.py skopiowany, tak samo jak link_crypto — usługi są osobnymi obrazami i nie importują się nawzajem. DWIE RÓŻNICE WOBEC PEŁNEJ WERSJI, obie wynikające z tego, że demo nie ma własnego wolumenu: * nazwa ciasteczka jest inna. Gdyby obie aplikacje stanęły kiedyś pod jedną domeną, ciasteczka o tej samej nazwie nadpisywałyby się i człowiek wypadałby z jednej, logując się do drugiej. * nie ma licznika pokolenia sesji, bo nie ma go gdzie zapisać. Zdalne unieważnienie robi się przez DEMO_USERS: usunięcie konta albo zmiana hasła NATYCHMIAST ubija jego otwarte sesje, bo odcisk poświadczenia w ciasteczku przestaje pasować. Osobny test tego pilnuje. Wylogowanie i tak działa natychmiast, bo polega na skasowaniu ciasteczka. Klucz podpisu jest WŁASNY, nie ten z pełnej aplikacji: demo i produkcja nie mają powodu uznawać nawzajem swoich sesji, a wspólny klucz znaczyłby, że sesja z demo bywa ważna tam, gdzie nie powinna. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Pull request closed