Zaznaczone pole wyboru w formularzu nie wystarczy, aby zbudować wiarygodny proces uzyskiwania zgody. Aplikacja musi wiedzieć, jakie upoważnienie zostało udzielone, do jakiej czynności, kiedy i w jakim zakresie; musi też móc zaprzestać działania po wycofaniu zgody. Takie podejście ma szczególne znaczenie w przypadku funkcji opcjonalnych, takich jak komunikacja lub przetwarzanie, które nie są niezbędne do świadczenia głównej usługi.
Projektowanie obsługi zgody, którą można wycofać, w aplikacjach PHP wymaga rozdzielenia decyzji, które często zostają połączone w jedną flagę. Samo w sobie nie rozstrzyga, czy dana praktyka jest zgodna z obowiązującymi przepisami: przekłada decyzje produktowe i instrukcje sprawdzone przez specjalistów na weryfikowalne zachowanie techniczne.
Określ czynność i rozdziel pojęcia
Zacznij od opisania konkretnej czynności, która wymaga upoważnienia. „Akceptuję wszystko” trudno zinterpretować i odwołać; „otrzymywanie wiadomości promocyjnych pocztą elektroniczną” lepiej określa cel i kanał. Jeśli cel lub zakres ulegną istotnej zmianie, nie zakładaj, że wcześniejsza zgoda automatycznie nadal obowiązuje.
Odróżniaj zgodę od powiązanych pojęć:
- Warunki korzystania: określają warunki umowne lub zasady dostępu; ich akceptacja sama w sobie nie oznacza upoważnienia do opcjonalnego przetwarzania.
- Preferencje: opisują wybory dotyczące prezentacji lub konfiguracji. Mogą wymagać zgody, ale nie zawsze ją oznaczają.
- Uprawnienia dostępu: określają, co uwierzytelniona tożsamość może robić w systemie. Wycofanie opcjonalnego upoważnienia nie powinno automatycznie dezaktywować konta.
- Zgoda: rejestruje decyzję dotyczącą określonego celu i zakresu, zgodnie z przyjętymi kryteriami funkcjonalnymi i prawnymi.
Opisz każdy cel w stabilnym katalogu, podając zrozumiały dla interfejsu opis oraz wewnętrzny identyfikator używany w kodzie. Unikaj ponownego używania ogólnego klucza, takiego jak accepted, dla różnych celów.
Modelowanie stanu i jego zmian
Przydatny model określa podmiot, cel, zakres, stan, źródło decyzji i znaczniki czasu. Podmiotem może być konto lub powiązana tożsamość; wybór zależy od tego, jak zgoda wiąże się z osobami, kontami i kanałami. Zapisuj tylko dane niezbędne do obsługi decyzji i jej wyjaśnienia.
Zamiast przedstawiać wszystko jako pozbawioną kontekstu wartość logiczną, przechowuj bieżący stan, który można odczytać, oraz — jeśli uzasadnia to wymóg audytowy — niezmienne zdarzenia zmian lub zapis w trybie append-only. Zdarzenie może zawierać:
- Identyfikator podmiotu i klucz celu.
- Zarejestrowane działanie, na przykład udzielenie lub wycofanie zgody.
- Obowiązujący zakres, taki jak kanał lub kategoria.
- Datę i godzinę serwera w spójnym formacie.
- Źródło, takie jak uwierzytelniony formularz lub przepływ administracyjny, bez gromadzenia nadmiarowych danych.
- Identyfikator korelacji lub wersję definicji, jeśli ułatwia to analizę zmian.
Rejestr zdarzeń zapewnia możliwość śledzenia, ale nie dowodzi automatycznie, że prośba była jasna, interfejs został właściwie zaprezentowany ani że decyzja jest prawnie ważna. Unikaj przechowywania niepotrzebnych kopii formularzy, adresów IP lub innych wrażliwych danych jako substytutu prawidłowego projektu.
W PHP skup operacje w usłudze domenowej, na przykład ConsentService, zamiast pozwalać każdemu kontrolerowi bezpośrednio zapisywać stan. Aktualizacja bieżącego stanu i dodanie zdarzenia powinny odbywać się w transakcji bazodanowej, jeśli korzystają z tego samego magazynu danych.
Sprawdzanie upoważnienia w punkcie wykonania
Interfejs może ukrywać opcję, jeśli użytkownik nie ma upoważnienia, ale nie jest to wystarczająca kontrola. Sprawdzenie musi nastąpić w punkcie inicjującym czynność: przed dodaniem wysyłki do kolejki, wykonaniem opcjonalnego przetwarzania lub wywołaniem zewnętrznej integracji. Oczekująca wiadomość utworzona przed wycofaniem zgody również musi zostać zweryfikowana przed wysłaniem.
Operacja domenowa może korzystać z interfejsu takiego jak ConsentRepository::isGranted($subjectId, $purpose, $scope). Nazwa jest przykładowa: wynik powinien uwzględniać bieżący stan, dokładny cel, zakres oraz wszelkie reguły wygaśnięcia lub wersjonowania określone przez produkt. Nie zamieniaj zgody na jeden kanał w upoważnienie do korzystania z innego.
Jeśli wykonanie jest asynchroniczne, przekazuj identyfikatory i ponownie odczytuj stan podczas przetwarzania zadania, zamiast ufać nieaktualnej kopii przesłanej z formularza. W przypadku awarii repozytorium jawnie określ zachowanie: w przypadku wrażliwej czynności opcjonalnej bezpieczniej jest zwykle jej nie wykonywać, dopóki nie uda się zweryfikować upoważnienia. Rejestruj awarię operacyjną, nie ujawniając niepotrzebnych danych.
Wycofanie zgody i propagowanie zmiany
Wycofanie zgody jest jawną zmianą stanu, a nie cichym usunięciem historii ani unieważnieniem sesji. Użytkownik może pozostać uwierzytelniony i zachować dostęp do usługi, podczas gdy dozwolona czynność opcjonalna zostaje zatrzymana. Podobnie wycofanie zgody nie oznacza automatycznie usunięcia wszystkich danych: ich przechowywanie, usunięcie lub dalsze przetwarzanie mogą podlegać odrębnym wymogom, które należy określić po uzyskaniu odpowiedniej porady.
Rejestrując wycofanie, zaktualizuj stan odczytywany przez aplikację i wygeneruj zdarzenie umożliwiające skoordynowanie dalszych zadań. Wskaż miejsca, do których trzeba propagować zmianę: zadania w kolejce, harmonogramy, systemy komunikacyjne i integracje. Aby uniknąć niespójnych skutków, stosuj wzorce takie jak transakcyjna tabela wyjściowa (outbox) i idempotentni konsumenci; określ, co ma się stać, jeśli integracja jest niedostępna.
Nie zawsze da się cofnąć już wykonany skutek, taki jak dostarczenie wiadomości. Dlatego rozróżniaj blokowanie przyszłych działań, anulowanie zadań, które jeszcze nie zostały wykonane, oraz korygowanie skutków już zaistniałych. Precyzyjnie przedstawiaj wynik i zachowaj mechanizm ponawiania lub operacyjnego przeglądu w przypadku błędów propagacji.
Testowanie granic, ponowień i częściowych awarii
Testy powinny obejmować cały cykl, a nie tylko sprawdzać, czy formularz zapisuje wybór. Uwzględnij udzielenie zgody, odmowę, wycofanie, zmianę celu i ponawiane żądania. Sprawdź, czy ponowne wycofanie zgody jej nie aktywuje oraz czy zduplikowane zdarzenia nie powodują powielonych wysyłek ani sprzecznych stanów.
- Sprawdź, czy czynność nie rozpoczyna się, gdy brak aktualnego upoważnienia dla danego celu i zakresu.
- Wycofaj zgodę po utworzeniu zadania i potwierdź, że konsument ponownie ją weryfikuje przed wykonaniem działania.
- Zasymuluj awarię między aktualizacją stanu a powiadomieniem integracji; sprawdź, czy proces uzgadniania stanu może dokończyć propagację.
- Przetestuj nieaktualne stany, brakujące dane i błędy repozytorium, stosując zdefiniowane bezpieczne zachowanie.
- Sprawdź, czy wycofanie zgody na jeden cel nie zmienia zgód na inne cele, uprawnień dostępu ani sesji.
Rejestruj metryki operacyjne i błędy przetwarzania, nie zamieniając logów technicznych w równoległe repozytorium danych osobowych. Regularnie sprawdzaj oczekujące zadania i rozbieżności między stanem centralnym a integracjami.
Uzgodnij odpowiedzialności przed wdrożeniem
Zespół produktowy powinien określić cele, zakres, treść i sposób wycofania zgody; zespół techniczny powinien egzekwować te decyzje na każdej ścieżce wykonania. Specjaliści ds. bezpieczeństwa i prawa mogą przeanalizować model zagrożeń, minimalizację danych, okresy przechowywania i obowiązującą interpretację. Implementacja nie zastępuje takiej weryfikacji.
Przed wdrożeniem udokumentuj, które czynności zależą od poszczególnych celów, kto może zmieniać ich definicje i jak naprawia się błędy. Dzięki temu zgoda przestaje być odosobnionym polem wyboru, a staje się weryfikowalnym, możliwym do prześledzenia i propagowania warunkiem w aplikacji PHP.
