Konto

Profil operatora, token KSeF i widoczne uprawnienia

Strona konta pokazuje użytkownikowi jego realny zakres pracy w systemie: dane profilu, status tokenu KSeF, obsługę hasła i e-maila oraz aktywne role z listą uprawnień opisanych po polsku.

Administracja Role i uprawnienia

Centrum samoobsługi użytkownika

Konto w ExKSeF nie jest tylko formularzem do zmiany hasła. To miejsce, w którym operator może sprawdzić, kim jest w systemie, czy ma zapisany token KSeF i z jakich ról wynika jego dostęp do menu, stron oraz akcji.

W sekcji ogólnej aplikacja pokazuje login, adres e-mail, informację o zapisanym tokenie KSeF oraz liczbę aktywnych ról. Pod spodem każda rola ma własną kartę z listą uprawnień. Nazwy uprawnień są prezentowane po polsku, z tego samego słownika, którego używa administracja przy zarządzaniu rolami.

Dzięki temu użytkownik nie musi zgadywać, dlaczego widzi tylko płatności, faktury zakupowe albo wybrane akcje administracyjne. Konto staje się czytelnym podglądem modelu bezpieczeństwa, a nie techniczną listą kluczy.

Profil i potwierdzenie adresu e-mail

Zmiana adresu e-mail jest obsługiwana jako świadoma operacja bezpieczeństwa. Użytkownik podaje nowy adres dwukrotnie, a system zapisuje go dopiero po walidacji. Taka zmiana unieważnia dotychczasowe potwierdzenie, dlatego na nowy adres wysyłany jest link aktywacyjny.

Potwierdzenie e-maila jest miękką aktywacją. Konto może działać, ale layout pokazuje czytelny baner, dopóki adres nie zostanie potwierdzony. Z banera można ponownie wysłać link, a endpoint potwierdzający odświeża również cookie zalogowanego użytkownika, żeby aplikacja nie trzymała starego stanu sesji.

link potwierdzający jest generowany przez Data Protection i ma ograniczony czas ważności,
brak SMTP nie blokuje pierwszego uruchomienia systemu,
zmiana e-maila wymaga ponownego potwierdzenia nowego adresu,
baner jest informacją operacyjną, a nie błędem blokującym pracę.

Hasło i reset dostępu

Zmiana hasła odbywa się wewnątrz konta po podaniu obecnego hasła oraz dwukrotnym wpisaniu nowego. System nie wykonuje cichej podmiany bez weryfikacji aktualnego sekretu, a komunikaty pozostają zrozumiałe dla użytkownika.

Poza samą stroną konta aplikacja ma też ścieżkę resetu hasła z formularza logowania. Token resetujący jest powiązany z aktualnym hashem hasła, więc po zmianie hasła traci ważność. To proste rozwiązanie daje efekt jednorazowego linku bez dokładania kolejnej tabeli z tokenami.

Token KSeF jako sekret użytkownika

Token KSeF jest zapisany przy konkretnym użytkowniku, ponieważ operacje KSeF mogą być wykonywane w imieniu wybranego konta. Sekcja konta pokazuje tylko stan sekretu: zapisany albo brak. Sam token nie jest wyświetlany ponownie.

Po wklejeniu tokenu aplikacja zapisuje go w postaci zaszyfrowanej. Jeśli token już istnieje, użytkownik widzi znacznik "Zapisany" i może wkleić nowy, aby zastąpić poprzedni. Ten sam wzorzec znacznika jest używany również przy innych zapisanych sekretach w administracji, więc operator rozpoznaje go jako informację o bezpiecznie zapisanej wartości.

Ten token jest później wykorzystywany przez procesy związane z KSeF, między innymi synchronizację faktur przychodzących oraz wysyłkę i odświeżanie statusów faktur sprzedażowych, gdy zadanie harmonogramu wskazuje użytkownika z zapisanym tokenem.

Jak konto wpływa na pracę w systemie

%%{init: {"themeVariables": {"fontSize": "12px"}}}%%
flowchart TD
  A[Administrator przypisuje uzytkownikowi role] --> B[Uzytkownik loguje sie do aplikacji]
  B --> C[System zapisuje role i status e-maila w sesji]
  C --> D[Menu i strony filtrują dostep wedlug uprawnien]
  D --> E[Strona Konto pokazuje aktywne role i polskie nazwy uprawnien]
  B --> F[Uzytkownik zapisuje token KSeF]
  F --> G[Procesy KSeF moga dzialac w imieniu wskazanego konta]
  C --> H{E-mail potwierdzony}
  H -->|Nie| I[Layout pokazuje baner z ponowna wysylka linku]
  H -->|Tak| J[Baner nie jest pokazywany]

Role widoczne dla użytkownika

ExKSeF obsługuje przypisanie wielu ról do jednego użytkownika. Konto pokazuje je oddzielnie, a w każdej roli wyświetla wynikową listę uprawnień. To ważne, bo w praktyce jedna osoba może mieć dostęp do płatności nadchodzących, druga do faktur zakupowych, a kierownik do akceptacji lub eksportu.

Widoczna lista uprawnień obejmuje obszary pracy rozdzielone zgodnie z rzeczywistym menu aplikacji: faktury przychodzące, faktury zakupowe, płatności nadchodzące, opłacone i cykliczne, faktury sprzedażowe w różnych widokach, proformy, kontrahentów, O→M, harmonogram, administrację oraz użytkowników i role.

To jest celowo dostępne z poziomu konta. Gdy użytkownik widzi mniej opcji niż administrator, może sam sprawdzić, czy wynika to z roli, zamiast trafiać na techniczny błąd 403 albo puste menu bez wyjaśnienia.

Co ta strona pokazuje o projekcie

Strona konta spina kilka warstw systemu: uwierzytelnianie cookie, tokeny czasowe Data Protection, szyfrowanie sekretów KSeF, repozytorium użytkowników, wielorolowy model uprawnień i wspólny słownik polskich etykiet. To niewielki ekran, ale dobrze pokazuje, że aplikacja nie traktuje bezpieczeństwa jako dodatku do interfejsu.

Najważniejsza decyzja projektowa polega na tym, że użytkownik widzi skutki konfiguracji ról w tym samym produkcie, w którym pracuje. Administracja definiuje role, menu i strony respektują te role, a konto pozwala zweryfikować aktualny stan bez zaglądania do bazy albo logów.