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

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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ę przeglądać ją 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 Google lub logowania Facebooka, lub jeśli musisz 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 z plików 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 oraz potencjalnych rozwiązań, 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ń

w tabeli są na wczesnym etapie rozwoju. Twoja opinia jest dla nas cenna i pomoże nam tworzyć przyszłość. Podziel się opinią na temat tych interfejsów API: Partitioned Poppins.

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

Najlepszym sposobem na sprawdzenie, czy zmiany w plikach cookie innych firm wpływają na proces logowania, jest przejście przez proces rejestracji, odzyskiwania hasła, logowania 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 otrzymywanie e-maila z 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ą 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 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ć dotknięte.

Logowanie jednokrotne (SSO) z wykorzystaniem zewnętrznych mechanizmów

Logowanie jednokrotne innej firmy umożliwia użytkownikowi uwierzytelnianie się za pomocą jednego zestawu danych logowania na jednej platformie, a następnie uzyskiwanie dostępu 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 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 korzysta z usług zewnętrznego dostawcy, może być konieczne wprowadzenie drobnych zmian, takich jak uaktualnienie biblioteki. Najlepszym rozwiązaniem jest zapytanie dostawcy o wskazania, jak pliki cookie innych firm wpływają na rozwiązanie i jakie podejście zaleca w przypadku jego usług. Niektórzy dostawcy będą przechodzić na inne rozwiązania bez użycia plików cookie innych firm, a w takim przypadku korzystający nie będą musieli niczego zmieniać.

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 na tej samej stronie. Przykładem może być witryna, która używa example.com w przypadku witryny głównej i login.example w przypadku procesu 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 produktów hostowanych w różnych domenach lub subdomenach. Takie rozwiązania mogą udostępniać sesję użytkownika w tych 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 („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ęcej pracy.
• Używanie zestawów powiązanych witryn (RWS) i interfejsu Storage Access API (SAA): zestaw powiązanych witryn 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 za pomocą interfejsu Storage Access API. Umożliwia to logowanie jednokrotne w przypadku tych RP, które znajdują się w tym samym 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 uwierzytelniającym rejestrowanie ograniczonego zestawu powiązanych źródeł, w których przypadku można tworzyć i używać danych logowania.
• Jeśli uwierzytniasz użytkowników w przypadku więcej niż 5 powiązanych domen, zapoznaj się z zarządzaniem uwierzytelnianiem federacyjnym (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 się zalogować za pomocą danych logowania 3-party-app.example lub innego zewnętrznego dostawcy.

Użytkownik klika „Zaloguj” i uwierzytelnia się w wyskakującym okienku 3-party-app.example. 3-party-app.exampleOkno wyskakujące ustawia własny plik 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 w witrynie 3-party-app.example.

Ten sam problem występuje, gdy użytkownik jest przekierowywany z top-level.exampledo 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 na części i niedostępny w ramkach iframe witryny 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 wewnątrz elementów dołączanych, a nie z wyskakujących okienek.

Innym proponowanym rozwiązaniem w tym przypadku jest partycjonowanie Poppinsów, które jest obecnie wdrażane.

Logowanie się przez media społecznościowe

Przyciski logowania takie jak Zaloguj się przez Google, Facebook Login i Zaloguj się 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 informacje o przechodzeniu na nowszą bibliotekę Google Identity Services do uwierzytelniania i autoryzacji.

Większość witryn korzystających z nowocszej biblioteki Google Identity Services 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 wycofania plików cookie innych firm. W razie potrzeby możesz też skorzystać z listy kontrolnej migracji do 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żki użytkownika, np. podczas uzyskiwania dostępu do danych o profilu użytkownika lub subskrypcjach i zarządzania nimi.

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, na przykład 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 sytuacji, gdy te dane powinny być odizolowane od website.example, CHIPS może pomóc zapewnić, aby element osadzony miał dostęp do potrzebnych informacji. Dzięki CHIPS widżet subscriptions.example umieszczony w witrynie 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 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 kilku witrynach, rozważ użycie Storage Access API, jeśli użytkownik wcześniej odwiedził streaming.example jako witrynę najwyższego poziomu, oraz zbiorów witryn powiązanych, jeśli zbiór website.example jest właścicielem streaming.example.

Od wersji 131 Chrome FedCM jest zintegrowany z interfejsem Storage Access API. Dzięki tej integracji, 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 osadzonym treścią, znajdziesz w przewodniku po osadzonych treściach.

Inne ścieżki użytkowników

Ścieżki użytkowników, które nie korzystają z plików cookie innych firm, nie powinny być w żaden sposób dotknięte zmianami 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 2 FA, powinny działać zgodnie z oczekiwaniami. Możliwe punkty złamania zostały opisane wcześniej. Więcej informacji o konkretnym interfejsie API znajdziesz na stronie stanu interfejsu API. Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem w  repozytorium GitHub przeznaczonym dla programistów korzystających z Piaskownicy prywatności.

Audytowanie 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.