Dlaczego wymuszone 2FA w Magento 2 tak bardzo boli na stagingu?
Każdy programista i tester pracujący z Magento zna ten scenariusz: stawiasz świeżą instancję developerską, odpalasz migrację bazy danych, wchodzisz pod /admin i wita Cię ekran konfiguracji Two-Factor Authentication. Na produkcji to absolutny standard i konieczność, która chroni sklep przed przejęciem konta. Na środowisku staging, dev czy w pipeline CI/CD wymuszone 2FA to po prostu czysty zgrzyt operacyjny.
Typowe środowisko testowe żyje według innych zasad niż produkcja. Z jednego konta technicznego korzysta pięcioosobowy zespół QA, zewnętrzny copywriter i project manager. Nikt nie chce parować firmowego telefonu z instancją stagingową, która za trzy dni zostanie zaorana i postawiona na nowo ze snapshotu. Kody QR wygasają, aplikacje authenticatora zapełniają się śmieciowymi wpisami typu „Staging Client X Test 4”, a zablokowany tester pisze na Slacku, że nie może dokończyć weryfikacji koszyka, bo zgubił klucz jednorazowy. Rozwiązaniem tego problemu jest darmowy przelacznik 2FA dla Magento, który przywraca pełną kontrolę nad mechanizmem uwierzytelniania w panelu administracyjnym.
Dlaczego komenda CLI i wyłączanie modułu to ślepa uliczka?
Od wersji Magento 2.4.0 Adobe wprowadziło moduł Magento_TwoFactorAuth jako twardą zależność, uniemożliwiając logowanie do panelu bez skonfigurowanego drugiego składnika. Deweloperzy radzą sobie z tym na kilka sposobów, ale większość z nich ma poważne wady architektoniczne:
- Wyłączenie modułu przez CLI: Komenda
bin/magento module:disable Magento_TwoFactorAuthniby działa, ale wyłącza moduł globalnie w plikuapp/etc/config.php. Jeśli trzymasz ten plik w repozytorium Gita (co jest standardem w poprawnym procesie CI/CD), ryzykujesz, że wyłączone 2FA przypadkowo wyląduje na serwerze produkcyjnym podczas najbliższego deploymentu. - Użycie komendy
bin/magento security:tfa:disable: Polecenie to deaktywuje wymuszenie dla konkretnego dostawcy, ale wymaga bezpośredniego dostępu do powłoki serwera (SSH). Tester, content manager czy klient sprawdzający postępy prac na stagingu nie mają i nie powinni mieć dostępu do konsoli serwera. - Ręczne czyszczenie tabel w bazie: Usuwanie powiązań z tabel
tfa_user_configrozwiązuje problem tylko do momentu kolejnego wymuszenia ponownej konfiguracji przez silnik Magento.
W praktyce potrzebny jest prosty, bezpieczny mechanizm: flaga konfiguracyjna dostępna bezpośrednio w panelu administracyjnym, którą można zdefiniować per środowisko – na przykład nadpisując wartość w pliku app/etc/env.php lub w konfiguracji bazy danych specyficznej dla stagingu.
Jak powstał fork modułu i co musieliśmy w nim naprawić?
W ekosystemie Magento istniał kiedyś moduł autorstwa wolfsellers, który dodawał prosty przełącznik w panelu admina. Niestety, jak setki innych przydatnych rozszerzeń dla Magento, projekt został porzucony lata temu. Oryginalny plik composer.json nie definiował poprawnych zależności dla nowszych wersji interpretera PHP, a zależność magento/module-two-factor-auth była sztywno zablokowana na przestarzałej gałęzi 1.*.
Próba instalacji tego modułu na nowoczesnym stacku technologicznym – Magento 2.4.8, 2.4.9 i PHP 8.3 lub 8.4 – kończyła się natychmiastowym konfliktem zależności w Composerze. W SISL postanowiliśmy wziąć sprawy w swoje ręce. W ramach naszej wewnętrznej inicjatywy reanimujemy wartościowe, zapomniane moduły open-source, dostosowując je do aktualnych standardów bezpieczeństwa, wydajności i kompatybilności z najnowszymi wersjami Magento 2.
Kod modułu został w całości sprawdzony pod kątem kompatybilności z Magento 2.4.9 oraz PHP 8.4. Usunęliśmy archaiczne ograniczenia wersji, wyczyściliśmy deklaracje typów i przygotowaliśmy stabilne repozytorium, z którego każdy może skorzystać bez opłat.
Kod źródłowy forka jest w pełni otwarty i dostępny publicznie w serwisie GitHub pod adresem SISL-source/module-enabledisabletfa.
Jak zainstalować i skonfigurować przełącznik 2FA krok po kroku?
Instalacja modułu sprowadza się do standardowej procedury opartej na Composerze. Nie wymaga żadnych modyfikacji w kodzie core Magento ani niebezpiecznych obejść.
- Dodaj repozytorium i zainstaluj paczkę za pomocą Composera w głównym katalogu projektu:
composer config repositories.tfa vcs https://github.com/SISL-source/module-enabledisabletfa composer require wolfsellers/module-enabledisabletfa:dev-main bin/magento module:enable WolfSellers_EnableDisableTfa bin/magento setup:upgrade - Włącz moduł i uruchom proces aktualizacji schematu bazy danych oraz kompilacji:
bin/magento module:enable SISL_EnableDisableTFAbin/magento setup:upgradebin/magento setup:di:compilebin/magento cache:flush - Zaloguj się do panelu administracyjnego i przejdź do: Stores > Configuration > Security > 2FA.
- Zmień wartość pola Enable 2FA na No i zapisz konfigurację.
Od tego momentu formularz logowania do panelu admina na danym środowisku nie będzie wymagał podawania kodu jednorazowego ani parowania aplikacji mobilnej. QA i programiści mogą logować się natychmiast po zresetowaniu bazy danych.
Gdzie leży haczyk? Żelazna zasada: NIE wyłączaj 2FA na produkcji
Jako butikowe studio wdrażające Magento w Polsce stawiamy sprawę jasno: ten moduł służy wyłącznie do optymalizacji pracy na środowiskach lokalnych, developerskich i stagingowych. Wyłączenie dwuskładnikowego uwierzytelniania na publicznie dostępnym środowisku produkcyjnym to rażące naruszenie higieny bezpieczeństwa.
Sklepy oparte na Magento 2 są nieustannym celem zautomatyzowanych ataków brute-force, wycieków baz haseł i prób wstrzykiwania złośliwego kodu przez przejęte konta administracyjne. Brak drugiego składnika na produkcji oznacza, że wystarczy jedno skompromitowane hasło pracownika, aby cały sklep, dane klientów i historia transakcji wpadły w ręce osób trzecich. Dlatego na serwerze produkcyjnym flaga powinna zawsze mieć wartość Yes (lub konfiguracja powinna być zablokowana na stałe w pliku konfiguracyjnym środowiska).
Dlaczego ratujemy zapomniane narzędzia open-source dla Magento?
Ekosystem Magento 2 ma ogromną zaletę: jest niesamowicie elastyczny. Ma też jednak wadę: koszty utrzymania drobnych narzędzi często przerastają małe agencje, przez co dziesiątki świetnych mikro-modułów ląduje w koszu jako abandonware przy każdej większej aktualizacji frameworka lub wersji PHP. W SISL nie lubimy wyważać otwartych drzwi ani patrzeć, jak dobre rozwiązania marnują się przez błędy w wersjonowaniu Composera.
Przeglądamy, naprawiamy i udostępniamy za darmo narzędzia, które sami wykorzystujemy w codziennej pracy przy wdrożeniach i utrzymaniu e-commerce. Jeśli Twój sklep wymaga uporządkowania architektury, audytu wydajności lub bezpiecznego procesu deploymentu bez niespodzianek na produkcji, napisz do nas – chętnie przyjrzymy się Twojemu projektowi.