- security-headers.conf: nosniff, X-Frame-Options, Referrer-Policy, HSTS,
Permissions-Policy i minimalny CSP; dolaczany w kazdym location z add_header,
bez dublowania naglowkow Spring Security na /api/.
- docker-compose.prod.yml: APP_JWT_SECRET bez wartosci domyslnej - brak zmiennej
zatrzymuje wdrozenie zamiast startu z jawnym sekretem.
- Obraz frontendu budowany przez npm ci z package-lock.json.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Logowanie z https://polskalokalnie.pl konczylo sie bledem 403, a nie 401 -
zadanie w ogole nie docieralo do logiki uwierzytelniania. Nginx terminuje TLS
i przekazuje ruch do backendu po http, wiec Spring widzi schemat http, podczas
gdy przegladarka przysyla Origin z https. Schematy sie roznia, wiec zadanie
jest traktowane jako cross-origin i sprawdzane wzgledem listy dozwolonych
originow, na ktorej byly wylacznie adresy lokalne i LAN. Frontend pokazywal
przy tym generyczny komunikat, bo odpowiedz CORS nie jest JSON-em z pole
"message".
Dodanie domeny produkcyjnej do listy przywraca poprawne zachowanie: zle haslo
zwraca 401 z czytelnym komunikatem, poprawne 200.
Poza tym:
- name: polskalokalnie w obu plikach compose. Bez tego Compose wyprowadza nazwe
projektu z nazwy katalogu, a na serwerze kazda z trzech aplikacji siedzi w
katalogu "app" - komenda bez -p wchodzila w stack innej aplikacji i podmieniala
w nim serwis backend.
- restart: unless-stopped na serwisach produkcyjnych. Kontenery polskalokalnie
mialy polityke "no" i jako jedyne na serwerze nie wstawaly po reboocie.
W pliku deweloperskim swiadomie tego nie ma - lokalnie kontenery nie powinny
startowac same przy kazdym uruchomieniu Dockera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
debian