Sprawdź wpływ zmian plików cookie innych firm na Twoje procesy logowania

Pliki cookie innych firm mogą być blokowane przez ograniczenia przeglądarki, ustawienia użytkownika, flagi dewelopera lub zasady przedsiębiorstwa.

Twoja witryna lub usługa musi zapewniać komfort obsługi wszystkim użytkownikom, niezależnie od tego, czy pliki cookie innych firm są dostępne.

Na tej stronie znajdziesz informacje o scenariuszach dotyczących tożsamości, które najprawdopodobniej zostaną dotknięte zmianami, a także odniesienia do możliwych rozwiązań.

Jeśli Twoja witryna obsługuje tylko przepływy w ramach tej samej domeny i subdomen, np. publisher.example i login.publisher.example, nie będzie używać plików cookie innych witryn, a zmiany dotyczące plików cookie innych firm nie powinny mieć wpływu na proces logowania.

Jeśli jednak Twoja witryna używa osobnej domeny do logowania, np. w przypadku logowania przez Google lub logowania przez Facebooka, albo jeśli Twoja witryna musi udostępniać uwierzytelnianie użytkowników w wielu domenach lub subdomenach, istnieje możliwość, że będziesz musiał(-a) wprowadzić zmiany w witrynie, aby zapewnić płynne przejście na inne rozwiązanie niż pliki cookie innych witryn.

Typowe ścieżki użytkownika

Wiele procesów związanych z tożsamością opierało się w przeszłości na plikach cookie innych firm. W tabeli znajdziesz niektóre typowe ścieżki użytkowników i potencjalne rozwiązania dla każdej z nich, które nie są zależne od plików cookie innych firm. W kolejnych sekcjach wyjaśnimy, dlaczego zalecamy takie podejście.

Zalecane alternatywne interfejsy API w przypadku typowych zastosowań

w tabeli są na wczesnym etapie rozwoju. Twoja opinia jest cenna i pomoże im w przyszłości. Podziel się swoją opinią na temat tych interfejsów API: Partitioned Popins.

Testowanie ścieżek użytkowników związanych z tożsamością

Aby sprawdzić, czy na Twój proces logowania mają wpływ zmiany dotyczące plików cookie innych firm, przejdź przez proces rejestracji, odzyskiwania hasła, logowania i wylogowywania z włączoną flagą testowania plików cookie innych firm.

Oto lista kontrolna elementów, które należy sprawdzić po ograniczeniu plików cookie innych firm:

• Rejestracja użytkownika: tworzenie nowego konta działa zgodnie z oczekiwaniami. Jeśli korzystasz z zewnętrznych dostawców tożsamości, sprawdź, czy rejestracja nowych kont działa w przypadku każdej integracji.
• Odzyskiwanie hasła: odzyskiwanie hasła działa zgodnie z oczekiwaniami, od interfejsu internetowego, przez CAPTCHA, po otrzymanie e-maila z prośbą o odzyskanie hasła.
• Logowanie: proces logowania działa w tej samej domenie i podczas przechodzenia do innych domen. Pamiętaj, aby przetestować każdą integrację logowania.
• Wylogowanie: proces wylogowywania działa zgodnie z oczekiwaniami, a użytkownik pozostaje wylogowany po zakończeniu procesu wylogowywania.

Sprawdź też, czy inne funkcje witryny wymagające logowania użytkownika nadal działają bez plików cookie z innych witryn, zwłaszcza jeśli wiążą się z wczytywaniem zasobów z innych witryn. Jeśli na przykład używasz sieci CDN do wczytywania zdjęć profilowych użytkowników, upewnij się, że nadal działa. Jeśli masz kluczowe ścieżki użytkownika, takie jak proces płatności, które wymagają zalogowania się, upewnij się, że nadal działają.

Rozwiązania do logowania

W tej sekcji znajdziesz bardziej szczegółowe informacje o tym, jak te procesy mogą zostać naruszone.

Logowanie jednokrotne z wykorzystaniem mechanizmów zewnętrznych

Logowanie jednokrotne (SSO) innej firmy umożliwia użytkownikowi uwierzytelnianie za pomocą jednego zestawu danych logowania na jednej platformie, a następnie dostęp do wielu aplikacji i stron bez konieczności ponownego wpisywania danych logowania. Ze względu na złożoność wdrażania rozwiązania SSO wiele firm decyduje się na korzystanie z usług zewnętrznego dostawcy, aby udostępniać stan logowania w wielu źródłach. Przykłady dostawców to Okta, Ping Identity, Google Cloud IAM i Microsoft Entra ID.

Jeśli Twoje rozwiązanie korzysta z usług dostawcy zewnętrznego, konieczne może być wprowadzenie drobnych zmian, np. uaktualnienie biblioteki. Najlepiej jest skonsultować się z dostawcą, aby dowiedzieć się, jak zależności od plików cookie innych firm wpływają na rozwiązanie i jakie podejście zaleca on w przypadku swojej usługi. Niektórzy dostawcy w sposób niewidoczny dla użytkowników przestaną korzystać z plików cookie innych firm. W takim przypadku strony ufające nie muszą wprowadzać zmian.

Wiele domen

Niektóre witryny używają innej domeny tylko do uwierzytelniania użytkowników, którzy nie kwalifikują się do korzystania z plików cookie tej samej witryny, np. witryna używająca domeny example.com jako głównej i domeny login.example do logowania. Może to wymagać dostępu do plików cookie innych firm, aby zapewnić uwierzytelnianie użytkownika w obu domenach.

Niektóre firmy mogą mieć wiele usług hostowanych w różnych domenach lub subdomenach. Takie rozwiązania mogą chcieć udostępniać sesję użytkownika w tych usługach, co może wymagać dostępu do plików cookie innych firm w wielu domenach.

Możliwe ścieżki migracji w tym scenariuszu:

• Aktualizacja umożliwiająca korzystanie z własnych plików cookie („pochodzących z tej samej witryny”): zmiana infrastruktury witryny, tak aby proces logowania był hostowany w tej samej domenie (lub subdomenie) co główna witryna, która będzie używać tylko własnych plików cookie. W zależności od konfiguracji infrastruktury może to wymagać większego nakładu pracy.
• Używaj zestawów powiązanych witryn i interfejsu Storage Access API: zestawy powiązanych witryn umożliwiają ograniczony dostęp do plików cookie w różnych witrynach w małej grupie powiązanych domen. W przypadku RWS nie jest wymagane wyświetlanie użytkownikowi prośby o dostęp do pamięci podczas korzystania z interfejsu Storage Access API. Umożliwia to logowanie jednokrotne w przypadku usługodawców, którzy znajdują się w tym samym obszarze RWS co dostawca tożsamości. RWS obsługuje jednak dostęp do plików cookie innych witryn tylko w przypadku ograniczonej liczby domen.
• Używaj interfejsu Web Authentication API: interfejs Web Authentication API umożliwia podmiotom polegającym (RP) rejestrowanie ograniczonego zestawu powiązanych źródeł, w których można tworzyć i używać danych logowania.
• Jeśli uwierzytelniasz użytkowników w więcej niż 5 powiązanych domenach, zapoznaj się z informacjami o zarządzaniu tożsamościami sfederowanymi (FedCM): FedCM umożliwia dostawcom tożsamości korzystanie z Chrome do obsługi przepływów związanych z tożsamością bez konieczności używania plików cookie innych firm. W Twoim przypadku „domena logowania” może pełnić funkcję dostawcy tożsamości FedCM i być używana do uwierzytelniania użytkowników w innych domenach.

Uwierzytelnianie z elementów do umieszczenia

Załóżmy, że element iframe 3-party-app.example jest osadzony na stronie top-level.example. Na stronie3-party-app.exampleużytkownik może zalogować się za pomocą 3-party-app.example danych logowania lub innego dostawcy zewnętrznego.

Użytkownik klika „Zaloguj się” i uwierzytelnia się w 3-party-app.examplewyskakującym okienku. Wyskakujące okienko 3-party-app.example ustawia własny plik cookie. Jednak element iframe osadzony na stronie top-level.example jest podzielony i nie ma dostępu do pliku cookie ustawionego w kontekście własnym na stronie 3-party-app.example.3-party-app.example

Ten sam problem wystąpiłby, gdyby użytkownik został przekierowany z top-level.example na 3-party-app.example i z powrotem. Plik cookie jest zapisywany w kontekście własnym 3-party-app.example witryny, ale jest podzielony i niedostępny w ramach elementu iframe 3-party-app.example.

W przypadku, gdy użytkownik odwiedził zagnieżdżoną domenę w kontekście najwyższego poziomu, dobrym rozwiązaniem jest interfejs Storage Access API.

Aby odejść od rozwiązań opartych na plikach cookie innych firm, zalecamy dostawcom tożsamości wdrożenie interfejsu FedCM API i wywoływanie go w elementach osadzonych, a nie w wyskakujących okienkach.

Inne proponowane rozwiązanie dla tego procesu, podzielone wyskakujące okienka, jest w trakcie wdrażania.

Logowanie przez platformy społecznościowe

Przyciski logowania, takie jak Zaloguj się przez Google, Zaloguj się przez Facebooka i Zaloguj się przez Twittera, są jednoznacznym sygnałem, że Twoja witryna korzysta z federacyjnego dostawcy tożsamości. Każdy dostawca tożsamości federacyjnej ma własną implementację.

Jeśli używasz wycofanej biblioteki Google Sign-In JavaScript Platform, możesz dowiedzieć się, jak przejść na nowszą bibliotekę Google Identity Services w celach związanych z uwierzytelnianiem i autoryzacją.

Większość witryn korzystających z nowszej biblioteki Google Identity Services usunęła zależność od plików cookie innych firm, ponieważ biblioteka będzie w sposób niewidoczny migrować do korzystania z FedCM w celu zapewnienia zgodności. Zalecamy przetestowanie witryny z włączoną flagą testowania wycofywania plików cookie innych firm i w razie potrzeby skorzystanie z listy kontrolnej migracji do FedCM, aby się przygotować.

Uzyskiwanie dostępu do danych użytkowników z elementów do umieszczenia i modyfikowanie ich

Osadzone treści są często używane w przypadku ścieżek użytkownika, takich jak dostęp do danych profilu użytkownika lub danych subskrypcji albo zarządzanie nimi.

Na przykład użytkownik może zalogować się w usłudze website.example, która zawiera widżet subscriptions.example. Ten widżet umożliwia użytkownikom zarządzanie danymi, np. subskrybowanie treści premium lub aktualizowanie informacji rozliczeniowych. Aby modyfikować dane użytkownika, osadzony widżet może potrzebować dostępu do własnych plików cookie, gdy jest osadzony na stronie website.example. W sytuacji, gdy te dane powinny być odizolowanewebsite.example, CHIPS może pomóc w zapewnieniu, że osadzony element będzie miał dostęp do potrzebnych informacji. Dzięki CHIPS subscriptions.examplewidżet osadzony na stronie website.example nie będzie mieć dostępu do danych o subskrypcji użytkownika w innych witrynach.

Rozważmy inny przypadek: film z streaming.example jest umieszczony na stronie website.example, a użytkownik ma subskrypcję premium streaming.example, o której widżet musi wiedzieć, aby wyłączyć reklamy. Jeśli ten sam plik cookie musi być dostępny w wielu witrynach, rozważ użycie interfejsu Storage Access API, jeśli użytkownik odwiedził wcześniej witrynę streaming.example jako witrynę najwyższego poziomu, oraz zestawów powiązanych witryn, jeśli zestaw website.example jest właścicielem witryny streaming.example.

Od Chrome 131 FedCM jest zintegrowany z interfejsem Storage Access API. Dzięki tej integracji, gdy użytkownik zaakceptuje prośbę FedCM, przeglądarka przyzna osadzonemu dostawcy tożsamości dostęp do niepodzielonej pamięci.

Więcej informacji o tym, który interfejs API wybrać do obsługi konkretnej ścieżki użytkownika z treściami osadzonymi, znajdziesz w przewodniku po osadzaniu.

Inne ścieżki użytkownika

Zmiany w sposobie obsługi plików cookie innych firm w Chrome nie powinny wpływać na ścieżki użytkowników, które nie korzystają z tych plików. Istniejące rozwiązania, takie jak logowanie, wylogowywanie czy odzyskiwanie konta w kontekście własnym, 2FA powinny działać zgodnie z przeznaczeniem. Potencjalne punkty pęknięcia zostały opisane wcześniej. Więcej informacji o konkretnym interfejsie API znajdziesz na stronie stanu interfejsów API.

Przeprowadź audyt witryny

Jeśli Twoja witryna korzysta z jednej ze ścieżek użytkownika opisanych w tym przewodniku, musisz przygotować witryny: przeprowadź audyt witryny pod kątem użycia plików cookie innych firm, przetestuj ją pod kątem awarii i przejdź na zalecane rozwiązania.