Доступ к файлам cookie может сильно измениться!

Два сценария, в которых вы можете столкнуться с проблемами

Для наших обычных разработчиков все еще существует множество сценариев, которые могут быть затронуты, и мы должны внести соответствующие изменения, прежде чем отключать их, например, следующие два сценария.

Сторонний файл cookie iframe

Первый сценарий — это когда нам нужно поделиться состоянием со встроенным сторонним iframe. Если мы уже разработали общий чат, его доменное имя support.chat.example, и у нас есть много бизнес-сайтов (например, retail.example), на которые мы хотим встроить это окно чата, как iframeиз . Эта встроенная служба чата может полагаться на Cookie для сохранения истории взаимодействия пользователя. Поскольку iframeимя домена и текущий веб-сайт преувеличены, поэтому iframeподсаженное Cookie принадлежит третьей стороне Cookie.

Если нет возможности настроить межсайтовый Cookietripartite , тогда нашей службе чата support.chat.example, возможно, придется больше полагаться на некоторые идентификаторы, которые родительский веб-сайт retail.exampleактивно передает им для сеанс первой стороны. Поскольку этот вид службы чата часто является общим, поэтому каждый веб-сайт, который встраивает support.chat.exampleслужбу чата, требует дополнительных настроек для передачи статуса, и это значительно увеличивает стоимость разработки и доступа.

В качестве альтернативы мы также можем разрешить службе чата support.chat.example запрашивать retail.example страницу на нашем веб-сайте JavaScript. Но это создает очень большой риск для безопасности, и это ненадежный метод. Аналогичные возможные сценарии включают в себя:

• Трехсторонний картографический сервис
• Подресурс CDNбалансировка нагрузки
• Headless CMSпровайдер
• Домены-песочницы для ненадежного пользовательского контента
• Трехсторонняя встроенная реклама

Файлы cookie сторонних сайтов

Кроме того, есть еще один сценарий. Это слишком узко, чтобы определить, что файлы cookie принадлежат третьим сторонам в соответствии с разными доменными именами. Ведь у компании не может быть только одно доменное имя:

Например, мы упомянули выше www.google.com и www.youtube.com, хотя имена доменов разные, такие файлы cookie также называются трехсторонними файлами cookie, но любой человек с проницательным взглядом может увидеть, что youtube находится в google, и эти два доменных имени принадлежат одному и тому же семейству.

Если сторонние файлы cookie отключены, нормальная возможность совместного использования файлов cookie под разными доменными именами компании будет недоступна, что окажет большое влияние на обычные потребности бизнеса. Распространенным сценарием является единый вход. Часто нам нужно войти в систему только один раз при входе на разные веб-сайты компании. Это связано с тем, что личная информация пользователя хранится в файле cookie общедоступной службы входа в систему. Если сторонние файлы cookie отключены, информация для входа не может быть передана. Давайте посмотрим, как решить две вышеупомянутые проблемы.

Независимый раздел файлов cookie (CHIPS)

Прежде всего, давайте посмотрим на независимый раздел файлов cookie ( ), включенный Chrome 114по умолчанию для всех пользователей CHIPS, который используется для решения проблемы трехстороннего iframeобщего состояния.

Как решить проблему?

Раздельное состояние Cookie (CHIPS) позволяет разработчикам размещать файлы cookie в «разделенном» хранилище, отдельном для каждого сайта верхнего уровня Cookie jar.

Chrome официально описывает это следующим образом: CHIPS – это важный шаг, помогающий службам плавно переходить на будущее без сторонних файлов cookie.

CHIPSВведен новый Cookieатрибут : Partitioned, который позволяет контексту верхнего уровня решать, какой Cookieразделить.

Например, если мы iframeembed , при нормальных обстоятельствах, если третья сторона Cookie отключена, C не сможет получить доступ к Cookieit.

Если C указывает атрибут Cookie для Partitioned, этот файл cookie будет сохранен в специальном секционированном банке. Он вступит в силу только тогда, когда сайт А встроит сайт С через iframe, и браузер определит, что файл cookie будет отправлен только тогда, когда сайт верхнего уровня будет А.

Когда пользователь посещает новый сайт, например сайт B, если он встраивает сайт C через iframe, то сайт C под сайтом B не может получить доступ к файлу cookie, установленному ранее для A.

Если пользователь посещает сайт C напрямую, он также не сможет получить доступ к этому файлу cookie.

Это решает проблему совместного использования файлов cookie iframe тремя сторонами, защищая при этом конфиденциальность пользователей.

как использовать?

Метод реализации также очень прост. Как упоминалось выше, если вы хотите сохранить на текущем веб-сайте Cookie три стороны, которыми необходимо поделиться, вам нужно всего лишь добавить атрибут Partitioned . Кроме того, существует предварительное условие, согласно которому Cookie должен иметь Secureатрибут :

Set-Cookie: name=ConardLi; SameSite=None; Secure; Path=/; Partitioned;

детали реализации

PartitionedАтрибут фактически изменяет механизм раздела хранилища файлов cookie, делая раздел более строгим. В приведенном выше примере мы https://support.chat.example iframe встроили на страницу https://retail.example. PartitionedДо , уникальный идентификатор раздела Cookie: support.chat.example, а после включения Partitioned уникальный идентификатор раздела становится ("https", "retail.example") + support.chat.example.

FirefoxВ режиме ETPstrict и приватном просмотре все сторонние сайты cookieпо умолчанию разделены на разделы, поэтому все межсайтовые сайты cookie по умолчанию будут разбиты на разделы в соответствии с сайтом верхнего уровня. Однако cookieразделение может вызвать некоторые непредвиденные проблемы, так как в определенных сценариях могут использоваться неразделенные сторонние ресурсы cookie.

SafariНекоторые Cookieразделения , но в итоге от них отказались, и в настоящее время три стороны полностью заблокированы Cookie. Одна из причин заключается в том, что разработчики могут быть запутаны. . Однако кажется, что какой-то Cookiepartition .

В настоящее время я Chrome думаю, что Cookieидея эвристического разбиения на разделы, предоставляемая . Он не только решает проблему межсайтового отслеживания, но и в определенной степени удовлетворяет потребности пользователей. Я надеюсь, что другие браузеры смогут извлечь из этого уроки.

Собственные наборы файлов cookie

Выше мы решили проблему трехстороннего совместного использования состояния iframe, Cookie First-Party Setsи то, что используется для решения проблемы пользовательского сбора файлов cookie, то есть он предоставляет Cookieспособ выборочного изменения некоторых из трех сторон. к одному.

Как решить проблему?

Как мы упоминали ранее, многие организации или компании имеют несколько доменных имен, поэтому слишком строго различать, принадлежит ли файл cookie первой стороне или третьей стороне, только по разнице в имени домена.

First-Party SetsЭто равносильно предоставлению возможности разработчикам веб-сайтов. Хотя некоторые файлы cookie являются сторонними в соответствии с разделением доменных имен, вы можете указать некоторые файлы cookie и поместить их в коллекцию. Специальная форма для чтения.

Иными словами, youtube.com、google.comхотя эти два доменных имени принадлежат одной и той же организации, вы Chrome этого не знаете. Вы можете сказать, что Chromeэти разные доменные имена принадлежат одной и той же организации, поместив их в коллекцию.

как использовать?

Согласно вышеизложенной идее решения задачи, два шага First-Party Setsявляются:

• Шаг 1: поместите разные доменные имена, которыми вы хотите Cookie поделиться, в коллекцию, а затем отправьте ее на Chrome;
• Шаг 2. Используйте специальный метод Chrome, предоставленный для чтения общих имен в этих коллекциях доменных имен Cookie;

В раннем предложении Cookie, samePaty был добавлен новый атрибут для , вы можете использовать этот атрибут, чтобы сообщить браузеру, какие файлы cookie должны использоваться тремя сторонами, а затем вам нужно указать общее доменное имя collection в каталоге развертывания веб-сайта, как я писал ранее. Статья, посвященная этому методу: Подробно объясните новый атрибут SameParty файла cookie.

Однако ограничения этого метода слишком слабы. Веб-сайты могут легко снова реализовать трехсторонний обмен файлами cookie, а стратегия совместного использования недостаточно прозрачна. Поэтому в Chrome решили отказаться от этого решения и реализовать более сложный метод. .

Сначала вам нужно предоставить файл JSON, в котором вы указываете, какие доменные имена должны быть Cookieshared , а затем вам нужно Pull Requestотправить этот файл JSON Chromeв Githubрепозиторий. предоставлено: https://github.com/GoogleChrome/first-party-sets

Кроме того, формат файла JSON должен соответствовать спецификации. Ниже приведен пример:

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com", "https://associate4.com"],
  "serviceSites": ["https://servicesite1.com"],
  "rationaleBySite": {
    "https://associate1.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://associate2.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://associate3.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://serviceSite1.com": "An explanation of how each domain in this subset supports functionality or security needs."
  },

  "ccTLDs": {
    "https://associate1.com": ["https://associate1.ca", "https://associate1.co.uk", "https://associate1.de"],
    "https://associate2.com": ["https://associate2.ru", "https://associate2.co.kr", "https://associate2.fr"],
    "https://primary.com": ["https://primary.co.uk"]
  }
}

При этом есть несколько ключевых понятий:

• ccTLDs Доменное имя: веб-сайт может обслуживать разные страны, и каждый регион имеет определенное доменное имя, например conardli.cn、conardli.jp、conardli.enetc.
• ServiceДоменное имя: веб-сайт может использовать определенное доменное имя для обеспечения безопасности или повышения производительности, но веб-сайты с разными доменными именами также могут нуждаться в совместном использовании идентификационных данных пользователей.
• AssociatedДоменное имя. В рамках одной организации может существовать несколько разных суббрендов, соответствующих разным доменным именам, например, google.com、youtube.comв этом случае.

PRПосле фиксации Googleкоманда вручную обновит Review и PR. (Я не знаю, что Chromeкоманда... После того, как сайтов стало больше, должно быть много PR каждый день. Такой метод обслуживания реально осуществим??)

После того, как ваша конфигурация JSON будет объединена командой Chrome, это не означает, что вы можете свободно делиться сторонними файлами cookie под этими доменными именами. Также нужно использовать спец. Ниже приведен демонстрационный код Storage Access API(SAA):

https://glitch.com/edit/#!/first-party-sets

Разберем его, в первую очередь, чтобы определить, поддерживает ли браузер этот API:

/* 
 * Judge broswer version by UA
 */
if (navigator.userAgentData.brands.some(b => { return b.brand === 'Google Chrome' && parseInt(b.version, 10) >= 108 })) {
  // Supported
} else {
  // Not supported
}

/* 
 * Judge SAA 和 rSAFor API can use
 */
if ('requestStorageAccess' in document) {
  // SAA available
} else {
  // SAA not available
}

if ('requestStorageAccessForOrigin' in document) {
  // rSAFor available
} else {
  // rSAFor not available
}

Используйте requestStorageAccess, чтобы определить, предоставил ли пользователь Cookieдоступ третьей стороне и доступ ко всему, что можно прочитать Cookie:

if ('requestStorageAccess' in document) {
document.requestStorageAccess().then(
      (res) => { console.log('permission application passed', res) },
      (err) => { console.log('reject', err) }
   );
}

Используйте requestStorageAccessForOrigin, чтобы прочитать данные трех сторон, совместно использующих указанное доменное имя Cookie:

if ('requestStorageAccessForOrigin' in document) {
document.requestStorageAccessForOrigin('https://first-party-sets.glitch.me');
   location.reload();
} else {
   window.alert('document.requestStorageAccessForOrigin not enabled.');
}

Наконец

Это тоже слишком хлопотно. Я предполагаю, что такой способ использования отпугнет многих разработчиков в будущем. . . Я надеюсь, что команда Chrome постарается сделать его проще в использовании, но First-Party Sets он вышел в стабильную версию, и я не думаю, что будет слишком много изменений, поэтому все хотят использовать третье лицо в будущем Cookie, боюсь, все будет не так просто...

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .