Chrome предлагает новый опыт выбора пользователем с помощью сторонних файлов cookie. Вам необходимо подготовить свой сайт для пользователей, которые предпочитают просматривать его без сторонних файлов cookie.
На этой странице вы найдете информацию о сценариях идентификации, которые, скорее всего, будут затронуты, а также ссылки на возможные решения.
Если ваш веб-сайт обрабатывает потоки только в одном домене и поддоменах, таких publisher.example и login.publisher.example , он не будет использовать межсайтовые файлы cookie, и на ваш процесс входа не повлияет третье- изменения файлов cookie вечеринки.
Однако если ваш сайт использует отдельный домен для входа, например, с помощью входа в Google или входа в Facebook , или вашему сайту необходимо использовать аутентификацию пользователя для нескольких доменов или поддоменов, есть вероятность, что вам придется внести изменения в свой сайт, чтобы обеспечить плавный переход от межсайтовых файлов cookie.
Типичные пути пользователя
Исторически сложилось так, что многие рабочие процессы идентификации полагались на сторонние файлы cookie. В таблице перечислены некоторые распространенные действия пользователя и потенциальные решения для каждого из них, которые не зависят от сторонних файлов cookie. В следующих разделах будут объяснены обоснования этих рекомендаций.
Рекомендуемые альтернативные API для распространенных случаев использования
| Путь пользователя | Рекомендуемые API |
|---|---|
| Вход через социальные сети | Для поставщиков удостоверений: внедрите FedCM. Для проверяющих сторон: обратитесь к своему поставщику удостоверений. |
Для поставщиков удостоверений или индивидуальных решений: связанные наборы веб-сайтов. | |
| Управление профилями пользователей | API доступа к хранилищу Сопутствующие наборы веб-сайтов ЧИПСЫ ФедКМ + САА |
| API доступа к хранилищу Сопутствующие наборы веб-сайтов ЧИПСЫ ФедКМ + САА | |
| Аутентификация | API доступа к хранилищу ФедКМ API веб-аутентификации science Разделенные Попины |
| Эти сценарии обычно не имеют зависимостей от сторонних файлов cookie и, как ожидается, не будут затронуты. |
Протестируйте свой путь пользователя, связанный с идентификацией
Лучший способ проверить, влияют ли на ваш процесс входа изменения сторонних файлов cookie, — это пройти через процессы регистрации, восстановления пароля, входа и выхода с включенным флагом проверки сторонних файлов cookie .
Это контрольный список того, что следует проверить, если вы ограничили использование сторонних файлов cookie:
- Регистрация пользователя: Создание новой учетной записи работает как положено. При использовании сторонних поставщиков удостоверений убедитесь, что регистрация новых учетных записей работает для каждой интеграции.
- Восстановление пароля: восстановление пароля работает должным образом: от веб-интерфейса до CAPTCHA и получения электронного письма для восстановления пароля.
- Вход в систему. Рабочий процесс входа в систему работает в одном домене и при переходе к другим доменам. Не забудьте протестировать каждую интеграцию входа в систему.
- Выход: процесс выхода работает должным образом, и пользователь остается в системе после выхода из системы.
Вам также следует убедиться, что другие функции сайта, требующие входа пользователя в систему, остаются работоспособными без межсайтовых файлов cookie, особенно если они включают загрузку межсайтовых ресурсов. Например, если вы используете CDN для загрузки изображений профиля пользователя, убедитесь, что это по-прежнему работает. Если у вас есть важные пользовательские действия, такие как оформление заказа, привязанные к входу в систему, убедитесь, что они продолжают работать.
Решения для входа в систему
В этом разделе вы найдете более конкретную информацию о том, как эти потоки могут быть затронуты.
Сторонняя система единого входа (SSO)
Сторонняя система единого входа (SSO) позволяет пользователю проходить аутентификацию с помощью одного набора учетных данных на одной платформе, а затем получать доступ к нескольким приложениям и веб-сайтам без необходимости повторного ввода своих данных для входа. Из-за сложности реализации решения единого входа многие компании предпочитают использовать стороннего поставщика решений, чтобы распределять состояние входа между несколькими источниками. Примеры поставщиков: Okta, Ping Identity, Google Cloud IAM или Microsoft Entra ID.
Если ваше решение зависит от стороннего поставщика, возможно, потребуются некоторые незначительные изменения, например обновление библиотеки. Лучший подход — обратиться к поставщику за рекомендациями о том, как зависимости от сторонних файлов cookie влияют на решение и какой подход они рекомендуют для своего сервиса. Некоторые поставщики автоматически перейдут со сторонних файлов cookie, и в этом случае проверяющим сторонам не потребуется обновлять их.
Несколько доменов
Некоторые веб-сайты используют другой домен только для аутентификации пользователей, которые не имеют права на использование файлов cookie того же сайта, например веб-сайт, использующий example.com для основного сайта и login.example для процесса входа в систему, для чего может потребоваться доступ к сторонним файлам cookie. убедитесь, что пользователь аутентифицирован в обоих доменах.
Некоторые компании могут размещать несколько продуктов в разных доменах или поддоменах. Такие решения могут захотеть разделить сеанс пользователя между этими продуктами, и этот сценарий может потребовать доступа к сторонним файлам cookie между несколькими доменами.
Возможные пути миграции для этого сценария:
- Обновление для использования основных файлов cookie («того же сайта») . Изменение инфраструктуры веб-сайта таким образом, чтобы поток входа в систему размещался в том же домене (или поддомене), что и основной сайт, который будет использовать только основные файлы cookie. Это может потребовать больше усилий, в зависимости от того, как настроена инфраструктура.
- Используйте наборы связанных веб-сайтов (RWS) и API доступа к хранилищу (SAA) : RWS обеспечивает ограниченный доступ к межсайтовым файлам cookie между небольшой группой связанных доменов. При использовании RWS не требуется никаких запросов пользователя при запросе доступа к хранилищу с помощью API доступа к хранилищу. Это позволяет использовать единый вход на тех RP, которые находятся в том же RWS, что и IdP. Однако RWS поддерживает доступ к межсайтовым файлам cookie только в ограниченном количестве доменов.
- Использовать API веб-аутентификации : API веб-аутентификации позволяет проверяющим сторонам (RP) регистрировать ограниченный набор связанных источников, для которых можно создавать и использовать учетные данные.
- Если вы выполняете аутентификацию пользователей в более чем 5 связанных доменах, изучите Federated Credentials Management (FedCM) : FedCM позволяет поставщикам удостоверений полагаться на Chrome для обработки потоков, связанных с идентификацией, без необходимости использования сторонних файлов cookie. В вашем случае ваш «домен входа» может выступать в качестве поставщика удостоверений FedCM и использоваться для аутентификации пользователей в других ваших доменах.
Аутентификация с помощью встраивания
Предположим, что iframe 3-party-app.example встроен в top-level.example . В 3-party-app.example пользователь может войти в систему либо с учетными данными 3-party-app.example , либо с помощью другого стороннего поставщика.
Пользователь нажимает «войти» и проходит аутентификацию во всплывающем окне 3-party-app.example . Всплывающее окно 3-party-app.example устанавливает основной файл cookie. Однако iframe 3-party-app.example встроенный в top-level.example разделен и не может получить доступ к файлам cookie, установленным в собственном контексте в 3-party-app.example .
Та же проблема может возникнуть, когда пользователь перенаправляется с top-level.example на 3-party-app.example и обратно. Файл cookie записывается в собственном контексте сайта 3-party-app.example , но он секционирован и недоступен в iframe 3-party-app.example .
В тех случаях, когда пользователь посетил встроенный источник в контексте верхнего уровня, API доступа к хранилищу является хорошим решением.
Чтобы перейти от решений, использующих сторонние файлы cookie, мы рекомендуем поставщикам удостоверений использовать API FedCM , а FedCM вызывается из встроенных файлов, а не из всплывающих окон.
Еще одно предлагаемое решение для этого потока — Partitioned Popins — находится на стадии реализации.
Вход через социальные сети
Кнопки входа, такие как «Войти через Google» , «Войти через Facebook» и «Войти через Twitter», являются верным признаком того, что ваш веб-сайт использует федеративный поставщик удостоверений . Каждый поставщик федеративных удостоверений будет иметь свою собственную реализацию.
Если вы используете устаревшую библиотеку платформы JavaScript для входа в Google , вы можете найти информацию о том, как перейти на более новую библиотеку Google Identity Services для аутентификации и авторизации.
Большинство сайтов, использующих новую библиотеку Google Identity Services, отказались от использования сторонних файлов cookie, поскольку библиотека автоматически перейдет на использование FedCM для совместимости. Мы рекомендуем протестировать ваш сайт с включенным флагом тестирования поэтапного отказа от сторонних файлов cookie и, при необходимости, использовать для подготовки контрольный список миграции FedCM .
Доступ и изменение пользовательских данных с помощью встраивания
Встроенный контент часто используется для действий пользователя, таких как доступ или управление профилями пользователей или данными о подписках.
Например, пользователь может войти на website.example , в который встроен виджет subscriptions.example . Этот виджет позволяет пользователям управлять своими данными, например подпиской на премиум-контент или обновлением платежной информации. Чтобы изменить пользовательские данные, встроенному виджету может потребоваться доступ к собственным файлам cookie, когда он встроен в website.example . В сценарии, где эти данные должны быть изолированы в website.example , CHIPS может помочь гарантировать, что встраивание может получить доступ к необходимой информации. При использовании CHIPS виджет subscriptions.example , встроенный в website.example не будет иметь доступа к данным о подписке пользователя на других веб-сайтах.
Рассмотрим другой случай: видео streaming.example встроено в website.example , а у пользователя есть премиум-подписка streaming.example , о которой виджет должен знать, чтобы отключить рекламу. Если к одному и тому же файлу cookie необходимо получить доступ на нескольких сайтах, рассмотрите возможность использования API доступа к хранилищу , если пользователь ранее streaming.example как верхний уровень, и наборы связанных веб-сайтов , если набор website.example владеет streaming.example .
Начиная с Chrome 131, FedCM интегрирован с API доступа к хранилищу . Благодаря этой интеграции, когда пользователь принимает приглашение FedCM, браузер предоставляет IdP доступ к неразделенному хранилищу.
Дополнительную информацию о том, какой API выбрать для обработки конкретного взаимодействия пользователя со встроенным контентом, можно найти в руководстве по встраиванию .
Другие пути пользователя
На действия пользователя, не использующие сторонние файлы cookie, не должны влиять изменения в том, как Chrome обрабатывает сторонние файлы cookie. Существующие решения, такие как вход в систему, выход из системы или восстановление учетной записи в собственном контексте (2FA), должны работать должным образом. Потенциальные места поломки были описаны ранее. Для получения дополнительной информации о конкретном API посетите страницу статуса API . О любых поломках сообщайте по адресу goo.gle/report-3pc-broken . Вы также можете отправить форму обратной связи или сообщить о проблеме на GitHub в репозитории поддержки разработчиков Privacy Sandbox .
Аудит вашего сайта
Если на вашем веб-сайте реализован один из этапов взаимодействия с пользователем, описанных в этом руководстве, вам необходимо убедиться, что ваши сайты подготовлены : проверить свой сайт на предмет использования сторонних файлов cookie, протестировать их на предмет поломок и перейти к рекомендуемым решениям.