brak zapisu IP i daty zgody

Brak zapisu IP i daty zgody to zbiorcze określenie luki zgodności uniemożliwiającej udokumentowanie okoliczności akceptacji.

Co oznacza brak zapisu IP i daty zgody

Brak zapisu IP i daty zgody oznacza, że system przechowuje sam fakt wybrania opcji akceptacji albo nie zapisuje wystarczających danych, aby później ustalić, kiedy i z jakiego źródła wykonano tę czynność. Adres IP, znacznik czasu oraz identyfikator wersji formularza nie są treścią zgody, lecz metadanymi zdarzenia. Pozwalają odtworzyć podstawowy kontekst operacji zapisanej w aplikacji internetowej, panelu administracyjnym lub systemie obsługi formularzy.

Adres IP identyfikuje punkt sieciowy widoczny dla serwera w chwili obsługi żądania. Nie zawsze wskazuje bezpośrednio konkretną osobę lub urządzenie, ponieważ po drodze mogą występować translacja adresów NAT, firmowy serwer proxy, brama operatora albo sieć komórkowa. Z tego powodu zapis IP nie powinien być interpretowany jako pewne ustalenie tożsamości użytkownika. Data zgody jest natomiast elementem chronologicznym. Bez niej nie da się wiarygodnie ustalić, czy akceptacja nastąpiła przed wykonaniem dalszej operacji, po zmianie treści komunikatu lub po aktualizacji konfiguracji formularza.

Jak powstaje luka w rejestrze zdarzeń

Problem może pojawić się już na etapie projektowania tabeli przechowującej zgody. Jeżeli rekord zawiera wyłącznie identyfikator użytkownika i wartość logiczną typu true, system wie, jaki jest aktualny stan, ale nie ma pełnej historii zmiany tego stanu. Podobna sytuacja występuje wtedy, gdy aplikacja zapisuje datę modyfikacji konta zamiast czasu konkretnego zdarzenia zgody. Są to dwa różne momenty i nie można ich bezpiecznie utożsamiać.

Drugim źródłem luki jest błędna obsługa żądania po stronie serwera. Formularz może wysłać informację o akceptacji, lecz warstwa aplikacyjna nie przekazuje adresu klienta do modułu audytowego albo zapisuje zdarzenie dopiero po nieudanej transakcji. Czas może również zostać pobrany z zegara przeglądarki, który jest ustawiony nieprawidłowo. Wiarygodniejszy jest znacznik generowany na serwerze, zapisywany w jednolitym formacie, najlepiej z informacją o strefie czasowej lub w czasie UTC. W systemach rozproszonych należy dodatkowo sprawdzić synchronizację zegarów, ponieważ różne serwery mogą rejestrować tę samą operację z odmiennymi godzinami.

Niepełność rejestru może wynikać także z błędnej konfiguracji odwrotnego proxy. Serwer aplikacji może widzieć adres proxy zamiast adresu klienta, a niekontrolowane przyjmowanie nagłówków takich jak X-Forwarded-For może pozwolić klientowi na podanie dowolnej wartości. Informacja o adresie źródłowym powinna być ustalana zgodnie z rzeczywistą topologią zaufanych proxy. Należy też obsłużyć zarówno IPv4, jak i IPv6, ponieważ odrzucanie jednego z tych formatów może prowadzić do pustych lub niekompletnych rekordów.

Skutki techniczne dla historii zgód

Rejestr pozbawiony IP i daty zgody utrudnia korelację zdarzeń w logach aplikacji, serwera HTTP, systemu uwierzytelniania i bazy danych. Gdy pojawia się reklamacja, incydent albo potrzeba sprawdzenia działania formularza, sam znacznik akceptacji nie pozwala ustalić kolejności operacji. Nie wiadomo, czy użytkownik zaakceptował aktualną wersję komunikatu, czy rekord został utworzony przez migrację danych, import z innego systemu albo ręczną zmianę administratora.

Brak daty uniemożliwia również poprawne rozdzielenie zgód udzielonych wielokrotnie. Jeżeli użytkownik wycofał wcześniejszą akceptację, a następnie zaznaczył pole ponownie, pojedyncza wartość w bazie nie pokazuje obu zdarzeń. W rozwiązaniu opartym na historii powinien istnieć osobny rekord dla każdej zmiany, z typem operacji, czasem serwerowym, statusem oraz identyfikatorem wersji formularza lub tekstu, którego dotyczyła czynność. Wartość IP powinna mieć ustalony sposób przechowywania i maskowania, aby nie mieszać różnych formatów ani nie tracić informacji potrzebnych do technicznego śledzenia zdarzeń.

Naprawa takiej luki nie polega na dopisaniu bieżącej daty do starych rekordów. Taka data opisywałaby moment uzupełnienia danych, a nie moment faktycznej zgody. Poprawne postępowanie wymaga rozdzielenia rekordów historycznych od nowych zdarzeń i jednoznacznego oznaczenia danych, których nie da się odtworzyć. Przed wdrożeniem zmiany należy przetestować zapis dla zwykłego formularza, ponownej akceptacji, wycofania zgody, błędu bazy, pracy za proxy oraz połączenia IPv6. Należy także sprawdzić, czy logi nie zawierają sprzecznych czasów i czy rekord powstaje tylko po potwierdzeniu operacji przez serwer.

Sprawdzenie aplikacji i komputera użytkownika

Diagnostykę należy rozpocząć od porównania trzech źródeł: danych wysyłanych przez przeglądarkę, żądania odebranego przez serwer oraz rekordu zapisanego w bazie. W narzędziach deweloperskich przeglądarki można sprawdzić metodę żądania, adres endpointu, kod odpowiedzi i zawartość przesyłanych pól, ale przeglądarka użytkownika nie powinna być traktowana jako wiarygodne źródło czasu serwerowego ani adresu IP. Następnie trzeba prześledzić kod odpowiedzialny za utworzenie rekordu i potwierdzić, że pola czasu oraz źródła są nadawane po stronie backendu.

Na komputerze problem może być widoczny jako brak potwierdzenia, powtarzające się żądania, zapis tylko części formularza albo różnica między stanem pola w interfejsie a stanem zapisanym na serwerze. Warto sprawdzić ustawienia daty i czasu systemowego, działanie rozszerzeń blokujących skrypty, pamięć podręczną przeglądarki oraz połączenie przez sieć firmową lub komórkową. Takie testy pomagają odróżnić błąd interfejsu od braku obsługi po stronie aplikacji. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i podzespołów, w tym diagnostykę problemów z działaniem oprogramowania na komputerze użytkownika.

Końcowy test powinien potwierdzić nie tylko obecność nowych pól, lecz także ich spójność z logami serwera i bazą danych. Dla każdego zdarzenia trzeba ustalić, czy znacznik czasu pochodzi z serwera, czy adres źródłowy został ustalony przez zaufaną warstwę sieciową oraz czy identyfikator wersji formularza nie zmienił się bez utworzenia nowego rekordu. Dopiero taki test pokazuje, czy luka została rzeczywiście usunięta, czy jedynie uzupełniono widok administracyjny o dane, których system nadal nie zapisuje w chwili akceptacji.