Panel serwera
i aplikacji webowych

SSH (konsola — CMD lub PowerShell). Użytkownik administracyjny: dabid.

tylko IP MOKATE Port 22 (SSH) jest osiągalny wyłącznie z sieci MOKATE — spoza niej połączenie nie przejdzie (dotyczy też tunelu RDP poniżej, bo idzie przez SSH).

Hasło administratora nie jest zapisane na tej stronie — ta strona jest publiczna (route / nie ma logowania Entra ID). Hasło trzymajcie w menedżerze haseł / prywatnej notatce.

RDP (pulpit zdalny) — MOKATE blokuje RDP spoza sieci, więc łączymy się przez tunel SSH. Najszybciej pobrać oba gotowe pliki:

Kolejność użycia:

1. Uruchom polacz-rdp.bat — otwiera tunel SSH z lokalnego portu 3390 na port RDP serwera. Zaloguj się (okno zostaw otwarte). Odpowiednik komendy:
   ssh -L 3390:localhost:3389 dabid@74.234.19.63kopiuj
2. Otwórz serwer.rdp, zatwierdź ostrzeżenia (OK / Zgadzam się) i zaloguj się na konto maszyny. Plik zawiera jedną linię:
   full address:s:localhost:3390kopiuj

Pliki możesz też stworzyć ręcznie — nazwa dowolna, ważne rozszerzenia .bat i .rdp.

Poprzednio jeden płaski plik. Od lipca 2026 konfiguracja jest rozbita na katalogi:

Ważne: główny include /etc/nginx/strony/*.conf; (w nginx.conf) wczytuje tylko pliki bezpośrednio w strony/. Pliki z strony/apps/ wczytuje osobny include .../apps/*.conf; wewnątrz bloku server{} w kartka.conf — bo zawierają gołe location{} bez własnego server{}.

Nauczone boleśnie: nigdy nie zostawiaj plików .bak w strony/ ani strony/apps/ — jeśli pasują do wzorca wildcard include, NGINX wczyta je i przy zduplikowanym server_name może po cichu wybrać stary, niezabezpieczony blok bez żadnego błędu w nginx -t. Backupy trzymamy poza /etc/nginx/ całkowicie (np. ~/nginx-backups/).

Po każdej zmianie przetestuj i przeładuj (test musi przejść, zanim reload wejdzie w życie):

Dodatkowa mapa potrzebna do obsługi WebSocketów w proxy:

NGINX obsługuje tylko jeden auth_request per lokalizację — druga deklaracja bezgłośnie nadpisuje pierwszą, bez błędu w nginx -t. Dlatego sprawdzenie sesji i sprawdzenie dostępu są połączone w jednym miejscu: authz.py (patrz punkt 03).

Każda nowa aplikacja musi mieć ROOT ustawiony nie na /, lecz na swój route (np. /raporty) — zarówno w samej aplikacji, jak i w konfiguracji NGINX.

Dwa niezależne pytania, dwa mechanizmy, jedna brama przed NGINX:

1. Uwierzytelnianie — czy to w ogóle Ty, zalogowany kontem @mokate.com.pl? Odpowiada oauth2-proxy (localhost:4180) — loguje do Entra ID i pamięta sesję w ciastku.
2. Autoryzacja — czy masz dostęp do TEJ konkretnej apki (np. targety, a nie innej)? Odpowiada authz.py (localhost:5098) — sprawdza tabelę SQL src.SerwerDostepyAplikacji (patrz punkt 06).

Przepływ dla chronionej apki (w pełni /targety/, /allegro_api/, /generator_produktow/ oraz /autoprezentacja/):

Jeśli sesja nieprawidłowa → 401 (przekierowanie na logowanie Microsoft). Jeśli sesja OK, ale e-mail nie ma wpisu w tabeli dostępów → 403. Błąd samego SQL (np. brak zmapowanego konta) jest traktowany fail-closed — jak brak dostępu, nie jak błąd 500. Wynik jest cache’owany 60s per (apka, e-mail), żeby nie odpytywać SQL przy każdym żądaniu.

Ryzyko: authz.py jest teraz punktem krytycznym logowania dla wszystkich apek za bramą — jeśli padnie, nikt się nie zaloguje, nawet jeśli sam oauth2-proxy działa. Monitoring (Uptime Kuma) jest jeszcze do wdrożenia.

Wspólne wylogowanie dla całego serwera (łączy wylogowanie z oauth2-proxy z sesją Entra):

Po przejściu bramy, aplikacja dostaje nagłówki, którym może ufać bez własnego logowania:

X-Name/X-Surname/X-UserName są percent-encoded, bo nagłówki HTTP nie dopuszczają polskich znaków diakrytycznych bezpośrednio — odbierająca apka musi zrobić unquote().

Szybkie zdekodowanie payloadu JWT do debugowania (bez weryfikacji podpisu — token już zweryfikował oauth2-proxy):

Podgląd żywych claimów w przeglądarce: /targety/diag/sql-token-claims (dekoduje X-Sql-Token i zwraca jako JSON).

Aplikacje bez logowania nie muszą przechodzić przez NGINX — mogą być dostępne bezpośrednio po publicznym IP i porcie (jak Generator zestawów czy Panel harmonogramu). /generator_produktow/ była wcześniej w tej sytuacji (stała za NGINX, ale bez żadnego logowania) — od 14.07.2026 jest już w pełni pod nową bramą, razem z /targety/ i /allegro_api/ (patrz „Stan migracji” wyżej).

Aby port był osiągalny z zewnątrz, trzeba go wystawić w Azure:

1. Otwórz Ustawienia sieci (przycisk powyżej) → Reguły → Utwórz regułę portu przychodzącego.
2. Ustaw Docelowy zakres portów na numer portu aplikacji.
3. Ustaw Źródło na My IP address, aby ograniczyć dostęp do sieci MOKATE.

Prosty, płaski słownik dostępu: kto ma prawo wejść do której apki. Baza mkt-sls-p-sqldb2, kolumny id, email, aplikacja.

Dodanie dostępu dla kogoś:

Nazwa aplikacji w tej tabeli to po prostu jej główny route/URL — pierwszy segment ścieżki (np. /targety/… → targety), liczony automatycznie przez wspólną mapę /etc/nginx/conf.d/authz_app_map.conf (patrz punkt 07). Tabela jest odpytywana delegowanym tokenem SQL zalogowanego użytkownika, nie kontem serwisowym — więc osoba musi też mieć zmapowane konto AAD w tej bazie (CREATE USER ... FROM EXTERNAL PROVIDER) i GRANT SELECT na tę tabelę, inaczej sprawdzenie kończy się (bezpiecznie) odmową dostępu.

1. W apps/<nazwa>.conf, w bloku location dodaj:
   include /etc/nginx/strony/snippets/authz-gate.conf; include /etc/nginx/strony/snippets/proxy-common.conf;kopiuj
   Nazwa apki liczy się automatycznie z jej głównego route/URL (pierwszy segment ścieżki, np. /<nazwa>/ → <nazwa>) przez wspólną mapę authz_app_from_path (patrz punkt 06) — nic więcej nie trzeba ustawiać. Zadbaj tylko, żeby nazwa apki w SQL (krok 4) była dokładnie tym segmentem.
2. Jeśli apka miała własne logowanie OIDC — wyłącz je najpierw (inaczej podwójny login). Apka powinna zamiast tego czytać nagłówki z bramy (punkt 04) — nowe apki nie muszą już implementować własnego logowania Entra wcale.
3. sudo nginx -t && sudo systemctl reload nginx
4. Dodaj wiersze w src.SerwerDostepyAplikacji dla uprawnionych e-maili (punkt 06).
5. Test w incognito: brak sesji → redirect na Microsoft; e-mail bez wpisu w SQL → 403; e-mail z wpisem → apka się wczytuje z poprawnymi nagłówkami.
6. Osobno, opcjonalnie: powyższe daje apce tylko logowanie (X-Email/X-Sql-Token itd.) — jeśli ta apka ma też wołać Microsoft Graph/SharePoint w imieniu użytkownika, to NIE jest częścią tego checklistu, tylko dodatkowy, osobny krok w authz.py — patrz punkt 09.

Wszystkie aplikacje startują automatycznie przez serwis systemd, który odpala jeden skrypt startowy:

Skrypt tworzy dwie sesje tmux — każdy panel podpisany nazwą aplikacji:

Podłączenie się:

Nawigacja między panelami (domyślny prefix Ctrl+b): strzałka — przeskok do panelu; o — cyklicznie następny panel; d — odłącz się (apki dalej działają w tle).

Aktualizacja apki po zmianach w repo (git już autoryzowany na serwerze):

1. Wejdź na właściwy panel, wciśnij Ctrl+C — zatrzymuje tylko apkę, powłoka panelu zostaje żywa.
2. git fetch && git pull — jesteś już w odpowiednim katalogu.
3. Jeśli zmieniły się zależności: pip install -r requirements.txt albo dotnet restore.
4. Strzałka w górę + Enter — odtwarza zapamiętaną komendę startową panelu.
5. Ctrl+b + d, żeby się odłączyć i zostawić apkę działającą w tle.

Nie trzeba restartować całego serwera ani systemctl restart mokate-server.service — to tylko odtworzyłoby wszystkie panele od zera. Do zwykłej aktualizacji kodu wystarczą powyższe kroki w jednym panelu.

Problem: niektóre apki muszą wołać Microsoft Graph (np. pobrać plik z SharePointa) W IMIENIU zalogowanego użytkownika. X-Sql-Token się do tego nie nadaje — jego „aud” to Azure SQL, Graph go odrzuci jako zły odbiorca. Azure AD v2 nie pozwala też zmieszać scope’ów z dwóch różnych zasobów w jednym logowaniu (AADSTS70011).

Wariant rozważony i odrzucony: token APLIKACYJNY Graph (client_credentials + uprawnienie Application „Sites.Read.All” + zgoda administratora). Działałby, ale dawałby appce dostęp do całego SharePointa tenanta, niezależnie od tego, kto jest zalogowany — świadomie zbyt szeroki zakres.

Rozwiązanie: authz.py sam prowadzi DRUGI, całkowicie niezależny od oauth2-proxy login OAuth2 (Authorization Code) do tej samej apki Entra „Logowanie DABiD”, scope’owany wyłącznie do Graph delegowanego (Sites.Read.All — ma już zgodę administratora sprzed migracji pod bramę, żadnej nowej zgody nie trzeba). Nowe endpointy (publiczne, NIE internal jak /authz/check):

Magazyn refresh tokenów — zaszyfrowany (cryptography.Fernet), bo authz.py sam go trzyma (oauth2-proxy swojego nie eksponuje przez żaden nagłówek):

Automatyzacja bez klikania: dla apek wymienionych w stałej APPS_NEEDING_GRAPH w authz.py (dziś allegro_api i autoprezentacja), /check zwraca 403 + nagłówek X-Needs-Graph-Bootstrap: 1, gdy user nie ma jeszcze połączonego Grafa (zamiast zwykłego 200) — nginx na tej podstawie cicho przekierowuje przez /authz/graph/connect i z powrotem. Dzięki prompt=none to 1-2 niewidoczne przeskoki (poniżej sekundy) — user tego nie zauważa. Dla apek spoza listy nic się nie zmienia.

Pułapek nginx, boleśnie znaleziony przy wdrożeniu — kolejność FAZ: if w TEJ SAMEJ lokalizacji co auth_request_set nie działa. if biegnie w fazie rewrite, PRZED fazą access (gdzie żyje auth_request/auth_request_set) — w momencie sprawdzania warunku zmienna jest jeszcze pusta, niezależnie od tego, co zwróci authz.py (potwierdzone empirycznie: add_header w tej samej lokalizacji widziało poprawną wartość, a if na tę samą zmienną i tak nie odpalał 302). Poprawka: przenieść if do NAZWANEJ LOKACJI wywoływanej przez error_page — internal redirect z error_page wykonuje się PO fazie access, więc zmienna ma już wartość (dokładnie ten sam mechanizm co error_page 401 = @oauth2_signin). Konsekwencja: auth_request rozróżnia tylko 2xx/401/403 (inny kod = 500) — więc /check musi zwracać 403 (nie 200+nagłówek) dla „trzeba podłączyć Graf”.

snippets/authz-gate.conf — dopisane obok istniejących linii z punktu 02 (i zamieniony error_page 403):

kartka.conf — nowa nazwana lokacja + nowa publiczna lokacja dla connect/callback:

Jak dodać kolejną apkę do X-Graph-Token:

1. Dopisz nazwę apki (dokładnie jej główny route/URL — pierwszy segment ścieżki, tak jak liczy go mapa authz_app_from_path, patrz punkt 06/07) do APPS_NEEDING_GRAPH w authz.py, zrestartuj panel app-authz (patrz punkt 08).
2. Po stronie kodu apki: czytaj nagłówek X-Graph-Token (analogicznie do X-Sql-Token) — nie próbuj samemu zdobywać tokenu Graph (żadnego MSAL/client_credentials/własnego OAuth). Uwaga na zadania w tle (wątki robocze bez kontekstu żądania HTTP) — nagłówek trzeba przechwycić w widoku, PRZED wejściem do wątku, i przekazać jako argument.
3. nginx i Entra już gotowe (wspólny snippet + wspólna rejestracja Entra) — nic więcej nie trzeba zmieniać po stronie infrastruktury.

Ważne zastrzeżenie znalezione przy wdrożeniu: delegowane Sites.Read.All daje dostęp TYLKO do tego, do czego zalogowany user REALNIE ma dostęp w samym SharePoincie (udostępnianie/ACL) — to nie jest blankietowe uprawnienie jak wersja aplikacyjna. Plik udostępniony tylko konkretnej osobie da 403 accessDenied innemu userowi mimo idealnie poprawnego tokenu/scope/zgody administratora — wygląda jak brak uprawnień w Entra, ale to zupełnie inna przyczyna (SharePoint). Diagnoza: otwórz plik bezpośrednio w SharePoincie (nie przez Graph) jako dany user — SharePoint pokaże czytelny ekran „poproś o dostęp”. Fix: doudostępnij plik „Osobom w organizacji z linkiem” zamiast linku „Określone osoby”.