Chrome proponuje nowy interfejs wyborczy dla użytkowników z plikami cookie innych firm. Musisz przygotować swoją witrynę pod kątem użytkowników, którzy zdecydują się na przeglądanie bez plików cookie innych firm.
Na tej stronie znajdziesz informacje o scenariuszach związanych z tożsamością, które mogą być najbardziej prawdopodobne, a także odniesienia do możliwych rozwiązań.
Jeśli Twoja witryna obsługuje tylko przepływy w ramach tej samej domeny i jej subdomen, np. publisher.example i login.publisher.example, nie będzie używać plików cookie na wielu stronach, a proces logowania nie powinien być zależny od zmian w plikach cookie innych firm.
Jeśli jednak do logowania w witrynie używana jest oddzielna domena, np. logowanie się przez Google lub logowanie przez Facebooka, albo jeśli trzeba stosować w niej uwierzytelnianie użytkowników w wielu domenach lub subdomenach, może się okazać, że trzeba będzie wprowadzić w niej zmiany, aby przejście od plików cookie pochodzących z innych witryn było płynne.
Typowe doświadczenia użytkowników
Wcześniej wiele procesów związanych z tożsamością polegało na plikach cookie innych firm. Tabela zawiera listę typowych ścieżek użytkowników i potencjalnych rozwiązań dla każdej z nich, które nie zależą od plików cookie innych firm. W następnych sekcjach wyjaśnimy, dlaczego te rekomendacje zostały wyświetlone.
Zalecane alternatywne interfejsy API do typowych zastosowań
| Ścieżka użytkownika | Zalecane interfejsy API |
|---|---|
| Logowanie się przez media społecznościowe |
W przypadku dostawców tożsamości: wdróż FedCM W przypadku podmiotów uzależnionych: skontaktuj się z dostawcą tożsamości |
| Wylogowanie z kanału głównego | W przypadku dostawców tożsamości: wdróż FedCM. |
|
W przypadku dostawców tożsamości lub rozwiązań niestandardowych:Powiązane zestawy witryn |
|
| Zarządzanie profilami użytkowników |
Interfejs Storage Access API Zestawy powiązanych witryn CHIPS FedCM |
|
Storage Access API Powiązane zestawy witryn CHIPS FedCM |
|
| Uwierzytelnianie |
Interfejs Storage Access API FedCM Web Authentication API scienceRozdzielone punkty Popins |
| W tych scenariuszach nie ma zwykle zależności od plików cookie innych firm i nie powinny one być na nie narażone. |
Testowanie ścieżek użytkowników związanych z tożsamością
Najlepszym sposobem na sprawdzenie, czy zmiany plików cookie innych firm wpływają na proces logowania, jest przejście rejestracji, odzyskiwania hasła, logowania się i wylogowywania z włączoną flagą testowania plików cookie innych firm.
Oto lista kontrolna, którą warto przejrzeć 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 wysyłanie e-maila z odzyskanym hasłem.
- Logowanie: proces logowania działa w tej samej domenie i podczas przechodzenia do innych domen. Pamiętaj, aby przetestować każdą integrację logowania.
- Wylogowanie się: proces wylogowywania się przebiega zgodnie z oczekiwaniami, a użytkownik pozostaje wylogowany.
Sprawdź też, czy inne funkcje witryny, które wymagają zalogowania się użytkownika, działają bez plików cookie między witrynami, zwłaszcza jeśli wiąże się to z wczytywaniem zasobów z innych witryn. Jeśli na przykład używasz CDN do wczytywania zdjęć profilowych użytkowników, upewnij się, że nadal działa. Jeśli masz kluczowe ścieżki użytkowników, takie jak płatność, które wymagają zalogowania, sprawdź, czy nadal działają.
Rozwiązania dotyczące logowania
W tej sekcji znajdziesz szczegółowe informacje o tym, jak te procesy mogą zostać zmienione.
Logowanie jednokrotne (SSO) przez inną firmę
Dzięki funkcji logowania jednokrotnego innej firmy użytkownik może uwierzytelniać się za pomocą jednego zestawu danych logowania na jednej platformie, a następnie uzyskiwać dostęp do wielu aplikacji i stron bez konieczności ponownego wpisywania danych logowania. Ze względu na złożoność wdrażania logowania jednokrotnego wiele firm decyduje się na korzystanie z usług zewnętrznego dostawcy, aby udostępniać stan logowania między wieloma źródłami. Przykładami dostawców są Okta, Ping Identity, Google Cloud IAM lub Microsoft Entra ID.
Jeśli Twoje rozwiązanie opiera się na zewnętrznym dostawcy, może być konieczne wprowadzenie drobnych zmian, takich jak uaktualnienie biblioteki. Najlepiej poprosić dostawcę o wskazanie, jak pliki cookie innych firm wpływają na rozwiązanie i jakie podejście zaleca w przypadku jego usługi. Niektórzy dostawcy będą przechodzić na inne rozwiązania bez udziału użytkowników. W takim przypadku strony trzecie nie muszą nic robić.
Wiele domen
Niektóre witryny używają innej domeny tylko do uwierzytelniania użytkowników, którzy nie kwalifikują się do plików cookie w tej samej witrynie. Przykładem może być witryna, która używa do witryny głównej domeny example.com, a do procesu logowania domeny login.example. W takim przypadku dostęp do plików cookie innych firm może być wymagany, aby uwierzytelnić użytkownika w obu domenach.
Niektóre firmy mogą mieć wiele produktów hostowanych w różnych domenach lub subdomenach. Takie rozwiązania mogą udostępniać sesję użytkownika w różnych usługach, co może wymagać dostępu do plików cookie innych firm w różnych domenach.
Możliwe ścieżki migracji w przypadku tego scenariusza:
- Aktualizacja w celu korzystania z własnych plików cookie („w tej samej witrynie”): 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ęcej pracy.
- Używaj zestawów powiązanych witryn (RWS) i Storage Access API (SAA): RWS umożliwia ograniczony dostęp do plików cookie z innych witryn między niewielką grupą powiązanych domen. W przypadku RWS nie trzeba wyświetlać użytkownikowi żadnego prompta, gdy prosi się o dostęp do pamięci masowej za pomocą interfejsu Storage Access API. Pozwoli to na logowanie jednokrotne w tych usługach objętych ograniczeniami w tej samej usłudze RWS co dostawca tożsamości. Jednak RWS obsługuje dostęp do plików cookie w różnych witrynach tylko w przypadku ograniczonej liczby domen.
- Używanie interfejsu Web Authentication API: interfejs Web Authentication API umożliwia stronom ufającym rejestrowanie ograniczonego zbioru powiązanych źródeł, w których przypadku dane logowania mogą być tworzone i używane.
- Jeśli uwierzytelniasz użytkowników w przypadku więcej niż 5 powiązanych domen, zapoznaj się z zarządzaniem poświadczeń federacyjnych (FedCM): FedCM umożliwia dostawcom tożsamości korzystanie z Chrome do obsługi procesów związanych z tożsamością bez konieczności korzystania z plików cookie innych firm. W Twoim przypadku „domena logowania” może służyć jako dostawca tożsamości FedCM i używać jej do uwierzytelniania użytkowników w innych domenach.
uwierzytelniania z umieszczonych elementów,
Załóżmy, że w witrynie top-level.example umieszczony jest element iframe 3-party-app.example. W 3-party-app.example użytkownik może logować się za pomocą danych logowania 3-party-app.example lub innego zewnętrznego dostawcy.
Użytkownik klika „Zaloguj się” i uwierzytelnia się w wyskakującym okienku 3-party-app.example. 3-party-app.example powoduje ustawienie własnego pliku cookie. Jednak iframe 3-party-app.example osadzony w witrynie top-level.example jest podzielony i nie ma dostępu do pliku cookie ustawionego w kontekście własnego pliku cookie w witrynie 3-party-app.example.
Ten sam problem może wystąpić w przypadku przekierowania użytkownika z top-level.example do 3-party-app.example i z powrotem. Plik cookie jest zapisywany w kontekście własnych plików cookie witryny 3-party-app.example, ale jest podzielony i niedostępny w ramce 3-party-app.example.
W przypadku, gdy użytkownik otworzył ukrytą domenę w kontekście najwyższego poziomu, dobrym rozwiązaniem jest interfejs Storage Access API.
Aby zrezygnować z rozwiązań wykorzystujących pliki cookie innych firm, zalecamy, aby dostawcy tożsamości stosowali interfejs FedCM API. Usługa FedCM była wywoływana z umieszczonych treści, a nie z wyskakujących okienek.
Trwa wdrażanie innego proponowanego rozwiązania tego procesu – Partitioned Popins.
Logowanie się przez media społecznościowe
Przyciski logowania takie jak Zaloguj się przez Google, Logowanie przez Facebooka i Logowanie przez Twittera są jednoznacznym sygnałem, że Twoja witryna korzysta z federowanego dostawcy tożsamości. Każdy dostawca tożsamości federacyjnej będzie miał własną implementację.
Jeśli używasz wycofanego interfejsu Google Sign-In JavaScript Platform, znajdziesz tu informacje o przechodzeniu na nowszą bibliotekę Google Identity Services do uwierzytelniania i autoryzacji.
Większość witryn korzystających z nowszej biblioteki usług tożsamości Google przestała polegać na plikach cookie innych firm, ponieważ biblioteka zostanie przeniesiona po cichu na korzystanie z FedCM, aby zapewnić zgodność. Zalecamy przetestowanie witryny z włączoną flagą testowania wycofywania plików cookie innych firm. W razie potrzeby możesz też skorzystać z listy kontrolnej migracji FedCM.
Dostęp do danych użytkowników z osadzonych treści i ich modyfikowanie
Treści osadzone są często używane w trakcie ścieżek użytkownika, np. podczas uzyskiwania dostępu do profilu użytkownika lub zarządzania danymi subskrypcji.
Użytkownik może na przykład zalogować się na stronie website.example, która zawiera widżet subscriptions.example. Ten widżet umożliwia użytkownikom zarządzanie ich danymi, np. subskrybowanie treści premium lub aktualizowanie informacji rozliczeniowych. Aby modyfikować dane użytkownika, wbudowany widget może potrzebować dostępu do własnych plików cookie, gdy jest wbudowany w website.example. W przypadku, gdy te dane powinny być izolowane w website.example, usługa CHIPS może pomóc zapewnić, aby element osadzenia miał dostęp do potrzebnych informacji. Dzięki CHIPS widżet subscriptions.example umieszczony w witrynie website.example nie ma dostępu do danych subskrypcji użytkownika na innych stronach.
Inny przykład: film z streaming.example jest umieszczony w witrynie website.example, a użytkownik ma subskrypcję premium streaming.example, o której musi wiedzieć widżet, aby wyłączyć reklamy. Jeśli ten sam plik cookie musi być dostępny w wielu witrynach, użyj interfejsu Storage Access API, jeśli użytkownik wcześniej odwiedził streaming.example jako witrynę najwyższego poziomu, oraz zbiorów powiązanych witryn, jeśli zbiór website.example jest właścicielem streaming.example.
Od wersji 131 Chrome FedCM jest zintegrowany z interfejsem Storage Access API. Gdy użytkownik zaakceptuje prośbę FedCM, przeglądarka przyzna dostawcy tożsamości dostęp do niepartycjonowanego miejsca na dane.
Więcej informacji o tym, który interfejs API wybrać do obsługi określonej ścieżki użytkownika z zawartością osadzonej, znajdziesz w przewodniku na temat osadzania treści.
Wylogowanie z kanału frontowego
Logowanie się w kanale frontalnym to mechanizm, który pozwala użytkownikowi wylogować się ze wszystkich powiązanych aplikacji, gdy wyloguje się z jednej usługi. Wylogowanie w kanale frontowym w ramach OIDC wymaga, aby dostawca tożsamości umieścił w ramach iframe kilka elementów iframe powiązanych z usługą zaufanego podmiotu, które korzystają z plików cookie tego podmiotu.
Jeśli Twoje rozwiązanie korzysta z dostawcy tożsamości, mogą być potrzebne drobne zmiany (np. uaktualnienie biblioteki). Aby uzyskać więcej wskazówek, skontaktuj się z dostawcą tożsamości.
Aby rozwiązać ten problem, zespół FedCM wypróbował funkcję logoutRPs. Umożliwiło to dostawcy tożsamości wylogowanie się z dowolnego dostawcy usług, dla którego użytkownik wcześniej zatwierdził komunikację dostawcy usług–dostawcy tożsamości. Ta funkcja nie jest już dostępna, ale jeśli jesteś nią zainteresowany(-a) lub potrzebujesz jej, zachęcamy do zapoznania się z propozycją wstępną i przesłania opinii.
Inne ścieżki użytkowników
Ścieżki użytkownika, które nie są oparte na plikach cookie innych firm, nie powinny być w żaden sposób zależne od zmian w sposobie obsługi plików cookie innych firm w Chrome. Istniejące rozwiązania, takie jak logowanie się, wylogowywanie czy odzyskiwanie konta we własnym kontekście (2FA), powinny działać prawidłowo. Potencjalne punkty złamania zostały opisane wcześniej. Więcej informacji o konkretnym interfejsie API znajdziesz na stronie z informacjami o stanie interfejsu API. Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem na GitHubie w repozytorium pomocy dla deweloperów Piaskownicy prywatności.
Audyt witryny
Jeśli Twoja witryna wdraża jedną z ścieżek użytkownika opisanych w tym przewodniku, musisz się upewnić, że Twoje witryny są gotowe: przeprowadź audyt witryny pod kątem używania plików cookie innych firm, przetestuj, czy nie występują problemy, i przejdź na zalecane rozwiązania.