Chrome proponuje nowe rozwiązanie, które daje użytkownikom możliwość wyboru w przypadku plików cookie innych firm. Musisz przygotować swoją witrynę na potrzeby 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 Twoja witryna używa osobnej domeny do logowania, np. logowania w Google lub logowania na Facebooku, lub jeśli Twoja witryna musi udostępniać uwierzytelnianie użytkownika w wielu domenach lub subdomenach, być może trzeba będzie wprowadzić w niej zmiany, aby zapewnić płynne przejście na pliki cookie między witrynami.
Typowe ścieżki użytkownika
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 |
Dostawcy tożsamości: zaimplementuj FedCM Użytkownicy: skontaktuj się ze swoim dostawcą tożsamości |
| Wylogowanie z front-endu | Dostawcy tożsamości: zaimplementuj FedCM. |
|
W przypadku dostawców tożsamości lub rozwiązań niestandardowych:Powiązane zestawy witryn |
|
| Zarządzanie profilem użytkownika |
Storage Access API Powiązane zestawy witryn CHIPS FedCM + SAA |
|
Storage Access API Powiązane zestawy witryn CHIPS FedCM + SAA |
|
| Uwierzytelnianie |
Storage Access API FedCM Web Authentication API sciencePopins partycjonowane |
| W tych scenariuszach nie ma zazwyczaj 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 dotyczące plików cookie innych firm mają wpływ na proces logowania, jest przejście przez proces rejestracji, odzyskiwania hasła, logowania i wylogowywania z włączoną opcją 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 otrzymywanie 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: proces wylogowania działa zgodnie z oczekiwaniami, a użytkownik pozostaje wylogowany po zakończeniu procesu wylogowania.
Sprawdź też, czy inne funkcje witryny, które wymagają logowania 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 obrazów w profilach użytkowników, sprawdź, czy 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) z wykorzystaniem zewnętrznych mechanizmów
Logowanie jednokrotne (SSO) innych firm umożliwia użytkownikowi uwierzytelnianie się za pomocą jednego zestawu danych logowania na jednej platformie, a następnie korzystanie z 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, np. uaktualnienia 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 tym scenariuszu:
- 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żyj zbiorów powiązanych witryn (RWS) i interfejsu Storage Access API (SAA): RWS umożliwia ograniczony dostęp do plików cookie w innych witrynach w ramach małej grupy 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. Umożliwia to logowanie jednokrotne w przypadku tych dostawców usług, którzy korzystają z tego samego dostawcy usług uwierzytelniających. 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 uwierzytelniającym rejestrowanie ograniczonego zestawu powiązanych źródeł, w których przypadku można tworzyć i używać danych logowania.
- Jeśli uwierzytelniasz użytkowników w przypadku więcej niż 5 powiązanych domen, zapoznaj się z zarządzaniem uwierzytelnianiem w federacji (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 pełnić rolę dostawcy tożsamości FedCM i służyć do uwierzytelniania użytkowników w innych domenach.
Uwierzytelnianie z poziomu elementów osadzonego
Załóżmy, że element iframe 3-party-app.example jest osadzony w witrynie top-level.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 występuje, gdy użytkownik jest przekierowywany z top-level.example na 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 przejść na rozwiązania, które nie opierają się na plikach cookie innych firm, dostawcy tożsamości powinni zastosować interfejs FedCM API. FedCM jest wywoływany z poziomu elementów dołączanych, a nie wyskakujących okienek.
Wdrażamy inne proponowane rozwiązanie dotyczące tego procesu, czyli popinsy z partycjami.
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 Library, 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 nie korzysta już z plików cookie innych firm, ponieważ biblioteka zostanie automatycznie przeniesiona na korzystanie z FedCM w celu zapewnienia zgodności. Zalecamy przetestowanie witryny z włączoną flagą testowania wycofywania plików cookie innych firm. W razie potrzeby możesz 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ę w usłudze 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 website.example nie będzie mieć dostępu do danych subskrypcji użytkownika w innych witrynach.
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, rozważ użycie 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ć dodatkowe wskazówki, skontaktuj się z dostawcą tożsamości.
Aby sprostać temu zadaniu, FedCM przetestował 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 z dostawcą 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żytkownika
Na ścieżki użytkowników, które nie opierają się na plikach cookie innych firm, nie powinny mieć wpływu zmiany w sposobie obsługi plików cookie innych firm w Chrome. Istniejące rozwiązania, takie jak logowanie, wylogowywanie lub odzyskiwanie konta w kontekście usług własnych i podwójnego uwierzytelniania, powinny działać zgodnie z oczekiwaniami. 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 dotyczącej Piaskownicy prywatności.
Audytowanie witryny
Jeśli Twoja witryna wdraża jedną z ścieżek użytkownika opisanych w tym przewodniku, zadbaj o jej przygotowanie: sprawdź, czy używa plików cookie innych firm, przetestuj, czy nie występują błędy, i przejdź na zalecane rozwiązania.