PrestaWard Authenticator

Co robi

Skradzione hasło nie powinno wystarczyć do uzyskania dostępu do Back Office. Moduł wprowadza drugi czynnik uwierzytelniający bez przekazywania sekretu do interfejsów API stron trzecich.

Jak to działa

Drugi czynnik to kody jednorazowego użytku (TOTP) generowane przez aplikację uwierzytelniającą na telefonie komórkowym. Jeśli zezwoli Pan/Pani na tę opcję dla danego profilu, pracownicy tego profilu mogą zamiast tego korzystać z ośmiocyfrowych kodów wysyłanych pocztą elektroniczną; jest to metoda mniej bezpieczna, ponieważ dostęp uzyska każda osoba mająca wgląd do skrzynki pocztowej; panel administracyjny oraz strona pracownika zawierają odpowiednie ostrzeżenie. Funkcja ta jest domyślnie wyłączona. Obsługa kluczy dostępu (passkeys) jest wbudowana, ale w tej wersji domyślnie wyłączona.
Każdy pracownik konfiguruje swój własny czynnik uwierzytelniający w sekcji „Moje uwierzytelnianie” za pomocą kodu QR generowanego w samym sklepie. Pierwsza rejestracja odbywa się w trybie przewodnika: należy zeskanować kod QR, wprowadzić kod, a następnie przejść do strony końcowej zawierającej kody odzyskiwania. Przycisk umożliwiający przejście do panelu administracyjnego (Back Office) aktywuje się dopiero wtedy, gdy pracownik pobrał, skopiował lub wydrukował te kody.
Moduł instaluje się w trybie „Wyłączony”. W trybie „Tylko audyt” rejestruje on dostępy bez blokowania użytkowników, a w trybie „Wymuś” wymaga uwierzytelnienia drugiego czynnika. Pracownik, który jeszcze nie skonfigurował drugiego czynnika, potwierdza swoje hasło i do czasu zakończenia konfiguracji może otworzyć wyłącznie sekcję „Moje uwierzytelnianie”.
Polityka jest definiowana dla całego sklepu i można ją dostosować w zależności od profilu oraz poszczególnych sklepów. W przypadku sieci sklepów obowiązuje polityka o najsurowszych wymaganiach.
Przed wymuszeniem obowiązkowej rejestracji można przyznać danemu profilowi okres prolongaty trwający od 3 do 14 dni. Pracownicy, którzy jeszcze się nie zarejestrowali, logują się w zwykły sposób; na każdej stronie Back Office widzą powiadomienie z datą, od której uwierzytelnianie dwuetapowe stanie się obowiązkowe, a panel pokazuje, ilu pracowników pozostało do zarejestrowania. Po upływie tego terminu funkcja „Wymuś” zostanie zastosowana jak zwykle.
Zaufane urządzenia (domyślnie 30 dni) pozwalają uniknąć konieczności wprowadzania kodu przy każdym logowaniu z urządzenia znanego systemowi. Każdy pracownik może je cofać pojedynczo.
Liczba prób wprowadzenia hasła i kodu jest ograniczona (domyślnie 5 prób wprowadzenia kodu co 5 minut i 15-minutowa blokada). Kod TOTP nie może być ponownie wykorzystany. Jeśli PrestaWard Captcha zabezpiecza dostęp do Back Office i odrzuca żądanie, niepowodzenie to wlicza się wyłącznie do limitu na adres IP, a nie do blokady konta atakowanego administratora: bot bez tokenu nie może już zablokować konta za pomocą zaledwie kilku żądań.
Co pewien czas polityka uwierzytelniania wieloskładnikowego (MFA) jest odnawiana z podpisem usługi PrestaWard Integrity. Do serwisu Integrity przesyłane są wyłącznie dane techniczne dotyczące instalacji, nigdy natomiast nie są przekazywane sekrety TOTP, kody odzyskiwania ani dane pracowników.

W przypadku zgubienia telefonu komórkowego przez pracownika

Osobiste kody odzyskiwania: każdy pracownik otrzymuje domyślnie 10 kodów jednorazowego użytku podczas konfiguracji swojego czynnika uwierzytelniającego i powinien przechowywać je poza sklepem.
Opcjonalne odzyskiwanie dostępu e-mailem: w drugim kroku pracownik może poprosić o przesłanie kodu na adres e-mail. Funkcja ta jest domyślnie wyłączona i może zostać aktywowana przez superadministratora.
Resetowanie uwierzytelniania wieloskładnikowego (MFA) z poziomu panelu administracyjnego, bez dostępu przez konsolę: superadministrator może zresetować drugi czynnik uwierzytelniający innego pracownika. Funkcja wymaga hasła administratora, nie może być użyta wobec siebie samego i usuwa authenticator, kody odzyskiwania, zaufane urządzenia oraz otwarte sesje pracownika, który przy następnym logowaniu musi zarejestrować się ponownie. Inne profile posiadające uprawnienia do edycji w panelu administracyjnym MFA mogą zresetować tylko pracowników o niższych uprawnieniach, a jedynie superadministrator może zresetować konto innego superadministratora. Każde zresetowanie oraz każda odrzucona próba zostają odnotowane w rejestrze dostępu.
Dostęp awaryjny przez konsolę, jako ostateczność: wymaga dostępu do serwera oraz jednorazowego klucza awaryjnego, który jest generowany w panelu administracyjnym MFA. Umożliwia zresetowanie czynników uwierzytelniających pracownika lub zawieszenie obowiązku stosowania MFA na godzinę, jeśli nikt nie może uzyskać dostępu. Czynność ta jest rejestrowana, a klucza nie można ponownie wykorzystać.

Wymagania

PrestaShop 1.7, 8 lub 9 oraz wersja PHP wymagana przez daną wersję PrestaShop (PHP 7.1 lub nowsza w przypadku PrestaShop 1.7).
Aplikacja do uwierzytelniania TOTP na telefonie komórkowym każdego pracownika, z wyjątkiem profili, dla których zezwoli Pan/Pani na wykorzystanie kodu wysyłanego pocztą elektroniczną jako drugiego czynnika uwierzytelniającego.
Aby umożliwić odzyskiwanie danych za pośrednictwem poczty elektronicznej, wysyłanie kodów pocztą elektroniczną oraz powiadomień, sklep musi mieć możliwość wysyłania wiadomości e-mail.
W przypadku kluczy dostępu (domyślnie wyłączonych) należy podać adres HTTPS w Back Office.
Polityka ogólna, lista pracowników, poczta elektroniczna i rejestry są dostępne wyłącznie dla superadministratorów. Pozostali pracownicy zarządzają wyłącznie własnymi sprawami.
Panel i komunikaty w dziewięciu językach.

Znane ograniczenia

Menedżer plików w rdzeniu PrestaShop (folder filemanager w panelu administracyjnym) nie uruchamia modułów, więc nie może wymagać drugiego czynnika uwierzytelniającego. W przypadku obowiązkowego uwierzytelniania wieloskładnikowego (MFA) należy odebrać ten dostęp profilom, które go nie potrzebują, lub zablokować go na serwerze WWW.
Ochrona stron Back Office opartych na Symfony wymaga wersji PrestaShop 1.7.7 lub nowszej. W starszych wersjach zabezpieczane są wyłącznie strony klasyczne.
Usługa internetowa oraz interfejs API administratora PrestaShop wykorzystują własne klucze i pozostają poza zakresem działania modułu.

Czego nie robi

Nie zabezpiecza dostępu Państwa klientów do sklepu: jedynie do Back Office.
Nie przesyła sekretów TOTP, kodów odzyskiwania ani danych pracowników do usług zewnętrznych.
Stopka wiadomości e-mail modułu nie zawiera linków, danych kontaktowych ani obrazów przechowywanych poza Państwa sklepem: logo GO ON Agency jest plikiem należącym do samego modułu, który jest udostępniany z Państwa sklepu.

Zweryfikowana kompatybilność

Wersja 0.0.16 przeszła pomyślnie testy laboratoryjne w PrestaShop 1.7, 8 i 9 w dniu 15 października 2026 r., zarówno w przypadku czystej instalacji, jak i aktualizacji z wersji 0.0.15. Wersja 0.0.15 przeszła pomyślnie testy laboratoryjne w PrestaShop 1.7, 8 i 9 w dniu 13 października 2026 r.: w przypadku czystej instalacji oraz aktualizacji z wersji 0.0.14 i 0.0.6, przy zachowaniu konfiguracji, kluczy TOTP oraz zaufanych urządzeń, bez błędów blokujących w logach. Wersja 0.0.13 została zweryfikowana w PrestaShop 1.7.8.11 z PHP 7.4, PrestaShop 8.2.7 z PHP 8.1 oraz PrestaShop 9.1.4 z PHP 8.5.

Główne funkcje

Rejestracja TOTP przy użyciu aktualnego hasła i lokalnie wygenerowanego kodu QR.
Sekrety zaszyfrowane algorytmem AES-256-GCM oraz jednorazowe kody odzyskiwania HMAC.
Blokowanie powtórnego wykorzystania kodu TOTP poprzez atomowe przesunięcie licznika.
Ochrona przed atakami typu „brute force” na hasło i uwierzytelnianie wieloskładnikowe (MFA) według adresu IP i tożsamości, z możliwością konfiguracji limitów i blokad.
IPv4, IPv6, CIDR, zaufane serwery proxy oraz listy sieci, przy czym lista bezpiecznych adresów nie pozwala pominąć uwierzytelniania wieloskładnikowego (MFA).
Zaufane urządzenia z tokenami 256-bitowymi, funkcją skrótu, terminem ważności i możliwością unieważnienia.
Samodzielna obsługa pracownika, oddzielona od globalnej administracji.
Polityki MFA według profilu i sklepu, z rozstrzyganiem w konfiguracji wielosklepowej według najbardziej rygorystycznej.
Konfigurowalne unieważnianie sesji i urządzeń po zmianie hasła.
Odzyskiwanie dostępu za pomocą kodów osobistych, opcjonalnego kodu wysyłanego pocztą oraz, w ostateczności, awaryjnego dostępu przez konsolę za pomocą klucza jednorazowego użytku.
Opcjonalny kod wysyłany pocztą elektroniczną podczas weryfikacji MFA, z terminem ważności, kluczem HMAC oraz limitami wysyłania.
Okres prolongaty dla danego profilu przed wymuszeniem drugiego czynnika uwierzytelniania, wraz z powiadomieniem w Back Office oraz monitorowaniem pracowników, którzy nie spełnili jeszcze tego wymogu.
Reset drugiego czynnika pracownika z poziomu administracji MFA, z hasłem administratora i zapisem każdej próby.
Ostatnia aktywność w panelu: podsumowanie w prostych zdaniach dotyczących ostatnich 30 dni rejestru dostępów (nowe logowania z danego adresu IP lub przeglądarki, powtarzające się nieudane próby, blokady, wykorzystane kody odzyskiwania oraz resetowania). Należy korzystać wyłącznie z własnego rejestru, bez geolokalizacji ani usług zewnętrznych, a także nie należy wyświetlać pełnych adresów: adresy e-mail są zamaskowane, a adresy IP zachowują jedynie swoją sieć /24 (IPv4) lub trzy pierwsze grupy (IPv6). Rejestr dostępów z łańcuchem integralności zachowuje dokładne wartości.
Rejestracja z przewodnikiem dla pierwszego czynnika, z końcową stroną zawierającą kody odzyskiwania, która wymaga ich pobrania, skopiowania lub wydrukowania przed kontynuowaniem.
Kody wysyłane pocztą elektroniczną jako opcjonalny drugi czynnik uwierzytelniający, wyłącznie dla profili, na które zezwoli Pan/Pani: ośmiocyfrowe, przechowywane wyłącznie jako hash z kluczem, ważne przez pięć minut, jednorazowego użytku i z limitem wysyłek. Pracownicy potwierdzają swoją skrzynkę pocztową jednorazowo. Funkcja „Tylko odzyskiwanie” działa tak jak dotychczas.
Moje uwierzytelnianie w skrócie: pasek stanu, karta dla każdej metody z jedną zwiniętą akcją, kody odzyskiwania, zaufane urządzenia oraz na końcu zwinięta „strefa zagrożenia”. Usunięcie uwierzytelniania wieloskładnikowego (MFA) wyjaśnia, co zostaje usunięte, a co zachowane: hasło, aktualny kod oraz wyraźne potwierdzenie; działanie to dotyczy wyłącznie pracownika, który się zalogował.
Statystyki z ostatnich 30 dni wraz z trendami dziennymi (logowania, zweryfikowane czynniki drugie, błędy hasła i drugiego czynnika, blokady, wykorzystane odzyskiwania dostępu oraz nowe zaufane urządzenia), zasięg rejestracji według profilu oraz stosowane metody. Wyświetla wyłącznie dane liczbowe z Państwa własnego rejestru logowań: nie pokazuje adresów IP ani adresów e-mail.
Bot, który nie pokona PrestaWard Captcha, nie może już zablokować konta administratora: ta usterka liczy się wyłącznie w ramach limitu na adres IP.
Synchronizacja z Integrity po otwarciu panelu za pomocą żądania w tle, które nie powoduje opóźnienia w wyświetlaniu strony.
Panel składający się z pięciu zakładek (Podsumowanie, Pracownicy i rejestracja, Polityka, Statystyki i rejestr aktywności oraz Konfiguracja) oraz jednej zakładki Pomoc techniczna, zawsze umieszczonej jako ostatnia: zakładka Podsumowanie wyświetla tryb, zakres rejestracji, awarie i blokady z ostatnich 24 godzin oraz maksymalnie jedną linię ostrzeżenia, a każda zakładka przechowuje wyłącznie własne ustawienia.
Rejestry połączone za pomocą algorytmu HMAC, z funkcją przechowywania danych, podpisanym eksportem, filtrami i paginacją.
Odpowiedniki powiadomień e-mailowych w PrestaShop 1.7, 8 i 9, z logo Państwa sklepu w nagłówku oraz, w stopce, logo GO ON Agency wraz z podpisem „PrestaWard by GO ON Agency”.
Wspólny pasek filtrów w rejestrze dostępów: selektory są rozmieszczone w siatce o równej szerokości, pole wyszukiwania i przycisk „Filtruj” znajdują się w tym samym wierszu, a działania dodatkowe są wyrównane do prawej strony.
Ujednolicony wygląd panelu we wszystkich czterech modułach PrestaWard: nagłówki sekcji, karty formularzy z neutralnymi obramowaniami i wspólne blokami rozwijanymi, statystyki wyświetlane w jednym wierszu oraz większe logo GO ON Agency w nagłówku. Główny przycisk otrzymuje jednolity kolor zgodny z identyfikacją wizualną marki, bez gradientu.
Minimalny okres kwarantanny bez możliwości nawigacji do momentu zakończenia uwierzytelniania wieloskładnikowego (MFA).
Rejestracja instalacji oraz polityka MFA podpisana przez Integrity, bez przekazywania sekretów TOTP, kodów odzyskiwania ani danych pracowników. Na ekranie modułu przycisk „Synchronizuj” aktualizuje połączenie.
Panel pomocy technicznej GO ON Agency z raportem diagnostycznym do pobrania. Raport ten pobiera pracownik posiadający uprawnienia do edycji po wybraniu konkretnego sklepu. Zawiera on wyłącznie informacje o wersjach, stanach i licznikach; nie zawiera ścieżek ani danych uwierzytelniających i nie jest wysyłany automatycznie.

Bezpieczne użytkowanie

Domyślnym trybem jest „Wyłączony”. Każdy pracownik konfiguruje swoje konto w sekcji „Moje uwierzytelnianie”; administrator weryfikuje wdrożenie, przechodzi do trybu „Tylko audyt” i włącza tryb „Wymuś” po sprawdzeniu odzyskiwania dostępu.

Dziennik zmian

0.0.16

Panel jest podzielony na zakładki: Podsumowanie (tryb, zakres rejestracji, awarie i zawieszenia z ostatnich 24 godzin oraz maksymalnie jedna linijka ostrzeżenia), Pracownicy i rejestracja, Polityka, Statystyki i dziennik aktywności oraz Ustawienia. Panel pomocy technicznej posiada własną zakładkę „Pomoc techniczna”, która zawsze znajduje się na końcu; stan Integrity wyświetla się poniżej wszystkich zakładek, a w nagłówku widnieje logo GO ON Agency. Każda zakładka przechowuje wyłącznie własne ustawienia.
Poprawia sytuację, w której żądanie, które nie przeszło weryfikacji PrestaWard Captcha, było uwzględniane przy blokowaniu konta administratora będącego celem ataku. Wcześniej żądania bez tokenu Captcha były traktowane jako nieudane próby wprowadzenia hasła, co powodowało, że bot mógł zablokować konto już po kilku żądaniach. Gdy PrestaWard Captcha zabezpiecza dostęp do Back Office i odrzuca żądanie, niepowodzenie to wlicza się wyłącznie do limitu na adres IP. Bez PrestaWard Captcha (lub w trybie Obserwacji) nic się nie zmienia.
Nowość: kody wysyłane pocztą elektroniczną jako opcjonalny drugi czynnik uwierzytelniający. W ustawieniach poczty elektronicznej należy wybrać opcję „Drugi czynnik (słabszy)”, a następnie włączyć tę funkcję dla każdego profilu pracownika. Pracownicy posiadający takie profile potwierdzają swoją skrzynkę pocztową jednorazowo za pomocą kodu wysłanego pocztą, a następnie mogą logować się za pomocą kodów wysyłanych pocztą: ośmiocyfrowych, przechowywanych wyłącznie jako hash z kluczem, ważnych przez pięć minut, jednorazowego użytku i z limitem wysyłek, podobnie jak obecne kody odzyskiwania. W ustawieniach oraz na stronie pracownika znajduje się ostrzeżenie, że są one mniej bezpieczne niż aplikacja uwierzytelniająca: każdy, kto ma dostęp do skrzynki pocztowej, może uzyskać dostęp do konta. Funkcja „Tylko odzyskiwanie” działa dokładnie tak samo jak dotychczas.
Nowość: wspomagana rejestracja pierwszego czynnika. Gdy pracownik musi się zarejestrować (lub znajduje się w okresie karencji), funkcja „Moje uwierzytelnianie” jest przewodnikiem: zeskanowanie kodu QR, wprowadzenie kodu oraz strona końcowa potwierdzająca pomyślne zakończenie z kodami odzyskiwania (do pobrania, skopiowania lub wydrukowania). Przycisk „Przejdź do Back Office” działa dopiero po pobraniu, skopiowaniu lub wydrukowaniu kodów. Klucze dostępu oraz kody wysyłane pocztą, o ile są aktywne dla danego pracownika, są udostępniane w sekcji „Inne sposoby zabezpieczenia konta”.
Moje uwierzytelnianie staje się przejrzystym podsumowaniem: pasek stanu (stan, metody, kody odzyskiwania i zaufane urządzenia), kompaktowa karta dla każdej metody (aplikacja uwierzytelniająca, klucze dostępu i kody wysyłane pocztą) z jedną zwiniętą akcją, karta kodów odzyskiwania, zwinięte zaufane urządzenia oraz, na końcu, zwiniętą „strefę zagrożenia”. Usunięcie MFA wyjaśnia teraz, co zostaje usunięte i co dzieje się dalej, zachowując przy tym czerwony przycisk, hasło, aktualny kod oraz wyraźne potwierdzenie. Działa ona nadal wyłącznie w odniesieniu do pracownika, który zalogował się, a informacja ta pozostaje w rejestrze dostępów z łańcuchem integralności.
Polityka prywatności: sekcja „Ostatnia aktywność” nie wyświetla już pełnych adresów. Adresy e-mail są wyświetlane w postaci j***@d***.com, a adresy IP zachowują jedynie swoją sieć /24 (IPv4) lub trzy pierwsze grupy (IPv6), podobnie jak w sekcji „Statystyki”. Rejestr dostępów z ciągiem integralności zachowuje dokładne wartości i pozostaje wiarygodnym źródłem informacji.
Nowość: Statystyki. Nowa sekcja przedstawia dane z ostatnich 30 dni w postaci krótkich trendów dziennych (logowania, zweryfikowane czynniki drugiego czynnika, błędy hasła, błędy drugiego czynnika, blokady, wykorzystane odzyskiwania dostępu oraz nowe zaufane urządzenia), wraz z danymi dotyczącymi rejestracji pracowników, którzy powinni się zarejestrować (według profilu), oraz stosowanych metod. Funkcja ta odczytuje wyłącznie dane dotyczące Państwa własnego rejestru logowań i nie wyświetla adresów IP ani adresów e-mail.
Klucze dostępu (passkeys: Touch ID, Face ID, Windows Hello oraz klucze bezpieczeństwa) jako drugi czynnik uwierzytelniający: kod jest zawarty w module, jednak funkcje te są domyślnie wyłączone i wymagają adresu HTTPS w Back Office. Administrator aktywuje je w ustawieniach, a każdy pracownik dodaje je w sekcji „Moje uwierzytelnianie”, podając hasło oraz aktualny kod.
Naprawia problem, w wyniku którego połączenie z Integrity ulegało pogorszeniu w Back Office „wszystkich sklepów”: identyfikator instalacji był zapisywany wyłącznie dla pierwszego sklepu, synchronizacja w tle odczytywała go jako pusty, co powodowało błąd „Invalid RSA public key”, a podłączony sklep przechodził w stan „rejestracja w toku”. Tożsamość jest obecnie odczytywana jako całość z zakresu globalnego (lub ze sklepu, w którym jest zapisana) w dowolnym kontekście; aktualizacja przenosi do zakresu globalnego tożsamość zapisaną w sklepie bez jej ponownego generowania, a jeśli nie można jej odczytać, stan Integrity pozostaje bez zmian, a ostatni błąd jest rejestrowany jako błąd lokalny.
Poprawia sytuację, w której instalacja z poziomu konsoli (prestashop:module install) tworzyła ustawienia PWA_* wyłącznie dla pierwszego sklepu, podczas gdy Back Office „wszystkie sklepy” odczytywał ustawienia globalne. Instalacja tworzy teraz ustawienia globalne, a aktualizacja kopiuje brakujące ustawienia z pierwszego sklepu, nie nadpisując żadnych istniejących wartości.
Nowość: wspólny pasek filtrów w rejestrze dostępów. Selektory są rozmieszczone w siatce o równej szerokości, pole wyszukiwania i przycisk „Filtruj” znajdują się w tym samym wierszu, a działania dodatkowe są wyrównane do prawej strony.
Wiadomości e-mail wysyłane przez moduł zawierają logo Państwa sklepu w nagłówku (z nazwą sklepu jako tekstem alternatywnym) oraz wspólną stopkę z logo GO ON Agency i podpisem „PrestaWard by GO ON Agency”, bez żadnych linków ani danych kontaktowych. Logo w stopce jest plikiem należącym do samego modułu, udostępnianym z Państwa sklepów.
Ujednolicony wygląd panelu we wszystkich czterech modułach PrestaWard: nagłówki sekcji, karty formularzy z neutralnymi obramowaniami i wspólne blokami rozwijanymi, statystyki wyświetlane w jednym wierszu oraz większe logo GO ON Agency w nagłówku. Główny przycisk otrzymuje jednolity kolor zgodny z identyfikacją wizualną marki, bez gradientu.
Koryguje sytuację, w której w PrestaShop 9 motyw panelu administracyjnego wyświetlał zakładki z podkreśleniem jako linki, a tytuły sekcji były pisane wielkimi literami. Wspólne style neutralizują to zjawisko wyłącznie w panelu PrestaWard, dzięki czemu PrestaShop 1.7 i 8 wyglądają tak samo jak dotychczas.
Naprawia błąd, w wyniku którego w PrestaShop 1.7 arkusz stylów modułu był odrzucany podczas rejestrowania go z numerem wersji w adresie. Obecnie plik jest sprawdzany i rejestrowany bez parametrów, dzięki czemu nowy wygląd pojawia się w wersjach 1.7, 8 i 9.
Poprawia błąd polegający na tym, że w PrestaShop 9 przy resetowaniu drugiego czynnika uwierzytelniającego innego pracownika oraz podczas synchronizacji z Integrity token bezpieczeństwa był sprawdzany metodą, której PrestaShop 9 nie stosuje, co mogło powodować odrzucenie tokenu. Obecnie weryfikacja odbywa się za pośrednictwem serwisu PrestaShop 9; w PrestaShop 1.7 i 8 sposób sprawdzania pozostaje bez zmian.
Gdy połączenie z Integrity nie może zostać zaktualizowane w danym momencie, panel wyświetla jeden komunikat: zapisane połączenie pozostaje ważne i zostanie automatycznie ponowione. Etykiety wszystkich zakładek są przetłumaczone na dziewięć języków.
Aktualizacja tworzy brakujące ustawienia globalne, wykonuje etap schematu (kolumna profilu dla kodów pocztowych i tabele kluczy dostępu) oraz utrzymuje kody pocztowe i klucze dostępu w stanie wyłączonym do momentu ich aktywacji przez administratora. W istniejącej instalacji nic się nie zmienia, dopóki administrator nie aktywuje danej opcji.

0.0.15

Nowość: przywrócenie drugiego czynnika uwierzytelniającego pracownika z poziomu panelu administracyjnego MFA. Jeśli ktoś zgubi telefon komórkowy i kody odzyskiwania, administrator nie potrzebuje już dostępu przez konsolę. Resetowanie powoduje usunięcie autentykatora i kodów odzyskiwania pracownika, zamknięcie jego zaufanych urządzeń oraz otwartych sesji, a pracownik musi ponownie się zalogować przy następnym dostępie. Wymagane jest podanie hasła administratora; nie można wykonać tej operacji na sobie samym, a superadministrator może zostać zresetowany wyłącznie przez innego superadministratora. Każde zresetowanie oraz każda odrzucona próba zostają odnotowane w rejestrze dostępu, a pracownikowi można wysłać powiadomienie pocztą elektroniczną.
Nowość: okres prolongaty przed wymuszeniem. W zasadach dotyczących profili można ustawić dla danego profilu okres od 3 do 14 dni, po upływie którego funkcja „Wymuś” zablokuje dostęp pracownikom, którzy jeszcze się nie zarejestrowali. Użytkownicy logują się jak zwykle i na każdej stronie Back Office widzą powiadomienie z datą, od której uwierzytelnianie dwuetapowe stanie się obowiązkowe; osoby, które już się zarejestrowały, nadal proszą o swój kod. Panel wyświetla termin dla każdego profilu oraz liczbę pracowników, którzy nie zarejestrowali się jeszcze. Profile bez okresu karencji działają tak samo jak w poprzednich wersjach.
Nowość: sekcja „Ostatnia aktywność” w panelu podsumowuje w prostych zdaniach ostatnie 30 dni rejestru dostępów: logowania z adresu IP lub przeglądarki, z których dany pracownik nie korzystał wcześniej, powtarzające się nieudane próby logowania, blokady, wykorzystane kody odzyskiwania oraz resetowania przeprowadzone przez administratora. Korzysta wyłącznie z własnego rejestru, bez geolokalizacji ani usług zewnętrznych.
Wykorzystanie osobistego kodu odzyskiwania lub kodu otrzymanego pocztą jest obecnie rejestrowane w dzienniku dostępu jako „Wykorzystany kod odzyskiwania”.
Aktualizacja dodaje dwie kolumny do zasad profilu (domyślnie bez okresu karencji) oraz rejestruje hook wyświetlający powiadomienie o okresie karencji.
Panel pomocy technicznej i diagnostyki znajduje się tuż przed sekcją Integrity, podobnie jak w pozostałych modułach PrestaWard, i w kontekście „wszystkie sklepy” nie znika już: wskazuje on, że należy wybrać sklep.
Arkusze stylów są ładowane wraz z wersją modułu, dzięki czemu nowy wygląd pojawia się po aktualizacji bez konieczności opróżniania pamięci podręcznej przeglądarki.
Synchronizacja z Integrity odbywa się przy każdym otwarciu panelu, za pomocą żądania w tle, które nigdy nie spowalnia działania strony, maksymalnie raz na minutę dla każdego sklepu.

0.0.14

Zalecana aktualizacja zabezpieczeń: wzmacnia kontrolę drugiego czynnika w Back Office, dzięki czemu dostęp do chronionych stron i działań jest możliwy dopiero po jej zakończeniu.
Rozszerza weryfikację MFA na ścieżki Back Office PrestaShop w wersjach od 1.7.7 do 9, które nie korzystają z klasycznego szablonu, takie jak eksporty i żądania AJAX.
Ogranicza liczbę prób we wszystkich sprawdzaniach kodu w sekcji „Moje uwierzytelnianie”, również w odniesieniu do poszczególnych pracowników korzystających z różnych adresów IP, oraz wymaga zweryfikowanej sesji w przypadku wprowadzania istotnych zmian na koncie.
Naprawia pętlę przekierowań w PrestaShop 9 podczas otwierania strony „Moje uwierzytelnianie” z oczekującym drugim czynnikiem uwierzytelniającym.
Pracownicy, których profile zostały utworzone po instalacji, mają już dostęp do sekcji „Moje uwierzytelnianie”.
Koryguje instalację oraz ponowne próby sprawdzania Integrity w PHP 7.1 i 7.2.
Odnawia podpisaną politykę MFA przed upływem terminu ważności i wyświetla powiadomienie w panelu, jeśli termin ten już upłynął.
Dodaje jednorazowy dostęp awaryjny przez konsolę w celu tymczasowego zawieszenia wymogu uwierzytelniania wieloskładnikowego (MFA), jeśli nikt nie może się zalogować. Jest to ostateczność: wymaga dostępu do serwera oraz klucza awaryjnego; zawieszenie trwa godzinę i jest rejestrowane. Pracownicy nadal odzyskują dostęp za pomocą swoich kodów osobistych lub opcjonalnego odzyskiwania dostępu e-mailem.
Tłumaczy wszystkie zdarzenia rejestru dostępu na dziewięć języków.

0.0.13

Koryguje kompilację kontenera Back Office w starszych wersjach bez pliku request_stack.
Zachowuje uwierzytelnianie wieloskładnikowe (MFA) oraz ograniczenie liczby prób logowania w PrestaShop 9; w przypadku braku wymaganego kontekstu odmawia dostępu.
Dodaje ograniczony ręczny raport diagnostyczny: należy go pobrać i dołączyć do zgłoszenia do pomocy technicznej wraz z opisem problemu oraz krokami do jego odtworzenia. Nie wysyła danych automatycznie.
Pełny interfejs w dziewięciu językach, z przetłumaczonymi tekstami i wskazówkami.

0.0.12

Poprawia kontroler testu rejestracji w PrestaShop 9 i wyświetla rzeczywistą przyczynę w przypadku niepowodzenia Integrity.
Aktualizuje wspólny wygląd Back Office i usuwa wbudowany mechanizm sprawdzania aktualizacji w edycji Addons.

0.0.11

Łatka zabezpieczająca: zatrzymuje automatyczne ponowne próby rejestracji w przypadku zmiany klucza rejestracyjnego sklepu oraz wyświetla wyraźne powiadomienie w Back Office.

0.0.10

Automatyczny heartbeat bez crona dzięki lokalnej nieblokującej sondzie i uwierzytelnionej komunikacji serwer–serwer z Integrity API.
Dane uwierzytelniające zapieczętowane dla każdego sklepu, podpisana polityka uwierzytelniania wieloskładnikowego (MFA) oraz ostatni ważny stan bez zdalnych wywołań podczas logowania.
Blokada atomowa, sześciogodzinny interwał oraz okres oczekiwania po wystąpieniu błędów w celu uniknięcia duplikatów.
Cykl życia i aktualizacja zweryfikowane w PrestaShop 1.7, 8 i 9.

0.0.9

Bezpieczne połączenie z Integrity dla każdego sklepu, zapieczętowane dane uwierzytelniające oraz synchronizacja z Back Office.
Podpisana polityka zdalna może jedynie wzmocnić lokalną politykę MFA i nigdy nie ingeruje w proces logowania.
Konfiguracja została uporządkowana w czterech zakładkach: „MFA i powiadomienia”, „Polityki profili pracowników”, „Próby i blokady” oraz „Sieć i adresy IP”.
Zasady dotyczące poszczególnych profili i sklepów zostały przeniesione do osobnej sekcji w celu oddzielenia ich od zasad ogólnych.
Z konfiguracji usunięto zbędne źródło aktualizacji: oficjalny kanał jest ustalany przez moduł.
Każde pole konfiguracyjne zawiera bezpośredni odnośnik do jego opisu w przewodniku obsługi.

0.0.8

Okres bezpieczeństwa dla pracowników w celu unieważnienia poprzednich sesji, wyzwań i urządzeń.
Możliwość skonfigurowania unieważnienia po każdej zmianie hasła, wyłącznie po odzyskaniu lub zmianie administracyjnej, albo nigdy.
Zasady „Dziedziczenie”, „Obowiązkowe”, „Opcjonalne” i „Wyłączone” według profilu i sklepu.
Superadministratorzy są zawsze objęci obowiązkiem w trybie „Wymuś”, a w konfiguracji wielosklepowej obowiązuje najbardziej rygorystyczna polityka.
Jednorazowy klucz awaryjny oraz odzyskiwanie wyłącznie za pośrednictwem konsoli, bez trwałego obejścia internetowego.
Opcjonalne odzyskiwanie dostępu e-mailem podczas uwierzytelniania wieloskładnikowego (MFA), z ośmiocyfrowym kodem, HMAC, pięciominutowym okresem ważności oraz ograniczeniem liczby wysyłek.
Zapisy połączone za pomocą HMAC, diagnostyka integralności, okres przechowywania od 30 do 730 dni oraz podpisany eksport w formacie JSON.
Idempotentna migracja 0.0.8 oraz zweryfikowana aktualizacja z wersji 0.0.7 w PrestaShop 1.7, 8 i 9.

0.0.7

„Bezpieczeństwo” podzielone na sekcje „MFA i powiadomienia”, „Próby i blokady” oraz „Sieć i adresy IP”, z funkcją atomowego zapisywania zmian.
Nawigacja między zakładkami za pomocą klawiatury, zachowanie zaznaczenia oraz automatyczne otwieranie panelu w przypadku błędów walidacji.
Rzeczywista paginacja rekordów w bazie danych z 25, 50 lub 100 wierszami na stronę.
Filtry wpisów według przedziału czasowego, pracownika lub adresu e-mail, zdarzenia, wyniku oraz adresu IP.
Przeprojektowuje nagłówek „Moje uwierzytelnianie” z lepszym kontrastem, hierarchią, dostosowaniem do urządzeń mobilnych i firmowymi skrótami.
Test poczty sprawdza transport i odbiorców bez konieczności aktywowania alertów operacyjnych.
Widoczna diagnostyka przesyłania danych w PrestaShop, z rozróżnieniem między serwerami przechwytującymi a rzeczywistymi serwerami SMTP.
Diagnozowanie błędów zgodne z plikami logów SwiftMessage oraz MailerMessage w PrestaShop 1.7, 8 i 9.
Usuwa zduplikowany prefiks sklepu w tematach wiadomości i wzmacnia alternatywny link do Back Office.
Wysyłka firmowa zweryfikowana za pomocą Exchange Online we wszystkich trzech obsługiwanych wersjach.
Panel aktualizacji ujednolicony z Snapshotem za pomocą PrestaWard Update Manifest v1, stan, poziom krytyczności i SHA-256.
Idempotentna migracja 0.0.7 oraz zweryfikowana aktualizacja z wersji 0.0.6 w PrestaShop 1.7, 8 i 9.

0.0.6

Transakcyjna ochrona przed atakami typu „brute force” na hasło i uwierzytelnianie wieloskładnikowe (MFA) według adresu IP i tożsamości.
Obsługa protokołów IPv4, IPv6, CIDR, zaufanych serwerów proxy, listy dozwolonych adresów oraz listy zablokowanych adresów.
Ograniczone powiadomienia o blokadach w celu zapobiegania sztucznym burzom pocztowym.
Kwarantanna serwera bez menu, skrótów ani treści Back Office.
Przeprojektowana sekcja „Moje uwierzytelnianie” obejmująca cztery etapy, dostępne etykiety, eksportowalne dane odzyskiwania oraz indywidualne unieważnianie.
Odpowiedniki wiadomości e-mail wraz z tłumaczeniami w PrestaShop 1.7, 8 i 9, z podaniem wyników według odbiorców.
Wzmocniony moduł sprawdzający: korporacyjny protokół HTTPS, bez przekierowań, TLS, limit treści oraz ścisła zgodność z manifestem w wersji 1.
Migracja 0.0.6, aktualizacja z wersji 0.0.5 oraz kompletne tabele zgodności dla wszystkich trzech obsługiwanych wersji.

0.0.5

Dostęp wieloetapowy: PrestaShop najpierw weryfikuje hasło, a następnie prosi o podanie kodu TOTP lub kodu odzyskiwania.
Sesja uwierzytelniona w kwarantannie, powiązana z pracownikiem i ograniczona do sekcji „Moje uwierzytelnianie” do czasu zakończenia procesu uwierzytelniania wieloskładnikowego (MFA).
Zablokowano dostęp boczny za pomocą bezpośrednich kontrolerów oraz żądań typu AJAX/XHR.
Obowiązkowa rejestracja dla pracowników i superadministratorów bez potwierdzonego kodu TOTP.
Poprawia obsługę zaufanych urządzeń w PrestaShop 9 i wiąże je z pracownikiem oraz przeglądarką.
Drugi czynnik został przeprojektowany w języku hiszpańskim z wykorzystaniem systemu wizualnego PrestaWard.
Rozszerzony przewodnik zawierający rzeczywiste zrzuty ekranu przedstawiające drugi czynnik w PrestaShop 1.7, 8 i 9.
Pełna czysta macierz testów: poczta, TOTP, ochrona przed replay, odzyskiwanie, zaufanie i kwarantanna.

0.0.4

Obowiązkowa rejestracja w sekcji „Moje uwierzytelnianie” dla kont bez TOTP, gdy tryb jest ustawiony na „Wymuś”.
Drugi etap logowania wyświetlany jest wyłącznie po zweryfikowaniu hasła.
Superadministratorzy objęci tym samym procesem uwierzytelniania osobistego.
Przeprojektowany i przetłumaczony na język hiszpański formularz logowania MFA.
Naprawia błąd 500 testowej wiadomości e-mail.
Oddzielna samoobsługa MFA dla każdego pracownika.
Polityka, zasoby, poczta i logi są dostępne wyłącznie dla superadministratora.
Nowoczesne i starsze uprawnienia przebudowano w sposób idempotentny.
Precyzyjna diagnostyka odbiorców, konfiguracji SMTP oraz transmisji.
Ujednolicony rzeczywisty adres IP w logach, ograniczanie liczby żądań (rate limiting), wiadomościach e-mail i zaufanych urządzeniach.
Zdarzenia i teksty w Back Office przetłumaczone na język hiszpański.
Nagłówki i układ graficzny dostosowane do rodziny PrestaWard.
Przywraca firmowy adres pomocy technicznej hola@go-onagency.es.
Aktualizacja do wersji 0.0.4 oraz czysta macierz w PrestaShop 1.7, 8 i 9.

0.0.3

Ujednolicona geometria wizualna dzięki PrestaWard Snapshot.
Zaufane urządzenia z możliwością odwołania, wykorzystujące losowe tokeny 256-bitowe przechowywane w postaci skrótu.
Pliki cookie typu Secure, HttpOnly oraz SameSite=Lax są ograniczone do Back Office.
Odpowiedniki alertów w integracjach typu legacy oraz Symfony.
Branding, linki do produktów, przewodnik, pomoc techniczna i adres e-mail do celów testowych.
Weryfikacja limitu żądań w PrestaShop 1.7, 8 i 9.

0.0.2

Rejestracja TOTP chroniona hasłem, z lokalnym kodem QR.
Jednorazowe kody odzyskiwania przechowywane w formacie HMAC.
Atomowa ochrona przed powtórnym użyciem kodu TOTP (replay).
Ograniczanie liczby żądań (rate limiting) według konta i adresu IP.
Integracje dotyczące starszego systemu logowania oraz PrestaShop 9 opartego na Symfony.
Rotacja tokenu uwierzytelniającego oraz wycofanie uwierzytelniania wieloskładnikowego (MFA) chronione hasłem i czynnikiem uwierzytelniającym.

0.0.1

Scaffold jest domyślnie wyłączony.
Tabele MFA, TOTP, pulpit nawigacyjny, audyt, logi, alerty oraz wstępne tłumaczenia.