Как добавить атрибут того же сайта в файлы cookie
Обновлено: 24.11.2024
OIDC Enterprise с form_post
Веб-сообщение (он же checkSession )
Атрибуты того же сайта
Допускаются следующие значения атрибутов:
Некоторые атрибуты файлов cookie, с которыми вы, возможно, знакомы, включают:
После получения браузер анализирует заголовки и соответствующим образом обновляет файл cookie.
Изменения файлов cookie браузера
Файлы cookie без установленного атрибута SameSite будут иметь нестрогий режим
Файлы cookie с параметром SameSite=none должны быть защищены; в противном случае они не могут быть сохранены в файле cookie браузера
Цель этих изменений — повысить безопасность и помочь смягчить атаки CSRF.
auth0 (обрабатывает сеансы пользователей)
auth0-mf (обрабатывает информацию, относящуюся к многофакторной аутентификации)
сделал (идентификатор устройства/агента пользователя)
На диаграмме ниже показано, что происходит во время нового взаимодействия. Конечный пользователь запрашивает страницу, которую ранее не посещал. Сервер меняет способ отображения, когда посетитель возвращается, и устанавливает увиденный файл cookie. Серая часть заголовка set-cookie — это фактический ключ = значение cookie. Красная часть — это атрибуты файлов cookie, которые браузер сохраняет в файле cookie, чтобы позже решить, следует ли включать пару ключ + значение файла cookie в запросы.
На следующей диаграмме показано, что произойдет, если вы сделаете один и тот же запрос, используя один и тот же сеанс просмотра. Запрос отправляется на тот же сервер, и, поскольку атрибуты файла cookie не запрещают отправку видимого файла cookie, он автоматически включается в запрос как заголовок файла cookie. Теперь сервер будет реагировать по-разному в зависимости от того, что он получил этот файл cookie.
Затронутые функции
В таблице ниже показано, как изменения атрибута SameSite могут повлиять на ваши приложения.
Вы можете заметить, что спецификации Google Chrome и Microsoft Edge для установки для SameSite значения undefined были изменены с SameSite по умолчанию на none на нестрогий.
Например, предположим, что вы создаете новый пользовательский интерфейс и имеете несколько служб, к которым вы подключаетесь через шлюз Auth0. На этом шлюзе вы создаете сеанс cookie. Если вы отправляете запрос из другого источника, вы можете увидеть это предупреждение в консоли Javascript:
Действия, которые необходимо предпринять
Чтобы подготовиться к этому изменению, вам необходимо:
Настройте приложение на использование SameSite=none, если оно использует response_mode=form_post при взаимодействии с Auth0 (обратите внимание, что Chrome не делает исключений даже для localhost )
SameSite — это проект стандарта IETF, предназначенный для обеспечения некоторой защиты от атак с подделкой межсайтовых запросов (CSRF). Проект стандарта, первоначально разработанный в 2016 году, был обновлен в 2019 году. Обновленный стандарт не имеет обратной совместимости с предыдущим стандартом. Наиболее заметными отличиями являются следующие:
Новые экземпляры HttpCookie по умолчанию будут иметь значение SameSite=(SameSiteMode)(-1) и Secure=false . Эти значения по умолчанию можно переопределить в разделе конфигурации system.web/httpCookies, где строка «Unspecified» является дружественным синтаксисом только для конфигурации для (SameSiteMode)(-1):
Если вы читаете это на языке, отличном от английского, сообщите нам в этом обсуждении на GitHub, хотите ли вы видеть комментарии к коду на своем родном языке.
Убедитесь, что web.config содержит следующее:
Убедитесь, что файл проекта содержит правильную версию TargetFrameworkVersion:
Убедитесь, что пакеты NuGet в проекте ориентированы на правильную версию платформы. Вы можете проверить правильную версию платформы, изучив файл packages.config, например:
В предыдущем файле packages.config пакет Microsoft.ApplicationInsights:
Изменения поведения декабрьского патча
- До исправления значение None означало:
- Атрибут вообще не выдавать.
- Значение None означает "Выдать атрибут со значением None".
- Значение SameSite (SameSiteMode)(-1) приводит к тому, что атрибут не создается.
Обзор влияния изменений на браузеры
Если вы установите исправление и создадите файл cookie с помощью SameSite.None , произойдет одно из двух:
- Chrome версии 80 будет обрабатывать этот файл cookie в соответствии с новой реализацией и не применять те же ограничения сайта для файла cookie.
- Любой браузер, который не был обновлен для поддержки новой реализации, будет использовать старую реализацию. Старая реализация говорит:
- Если вы видите значение, которое вам не понятно, проигнорируйте его и переключитесь на строгие ограничения для тех же сайтов.
Поэтому либо приложение ломается в Chrome, либо вы ломаетесь во многих других местах.
История и изменения
Проект спецификации SameSite 2019 года:
Известные проблемы
Служба приложений Azure — обработка файлов cookie SameSite
Поддержка старых браузеров
Код обнаружения браузера, используемый в примерах проектов в этом репозитории GitHub, содержится в двух файлах
Эти обнаружения являются наиболее распространенными агентами браузера, которые поддерживают стандарт 2016 года и для которых необходимо полностью удалить атрибут. Это не полная реализация:
- Ваше приложение может видеть браузеры, которых нет на наших тестовых сайтах.
- Вы должны быть готовы добавить обнаружения, необходимые для вашей среды.
В локальных установках IIS URL Rewrite – это необязательная функция, которую, возможно, потребуется установить.
Проверка приложений на наличие проблем с SameSite
- Формы входа
- Внешние механизмы входа, такие как Facebook, Azure AD, OAuth и OIDC
- Страницы, принимающие запросы с других сайтов
- Страницы в вашем приложении, предназначенные для встраивания в окна iframe.
Приложения, взаимодействующие с удаленными сайтами, например через сторонние входы, должны:
- Протестируйте взаимодействие в нескольких браузерах.
- Примените обнаружение браузера и устранение последствий, описанные в этом документе.
Протестируйте веб-приложения, используя клиентскую версию, которая поддерживает новое поведение SameSite. В Chrome, Firefox и Chromium Edge есть новые флаги функции отказа, которые можно использовать для тестирования. После того, как ваше приложение применит исправления SameSite, протестируйте его с более старыми версиями клиента, особенно с Safari. Дополнительные сведения см. в разделе Поддержка старых браузеров в этом документе.
Тест в Chrome
Google не предоставляет старые версии Chrome. Следуйте инструкциям на странице Загрузка Chromium, чтобы протестировать более старые версии Chrome. Не загружайте Chrome по ссылкам, полученным при поиске старых версий Chrome.
Начиная с Canary версии 80.0.3975.0, временное смягчение Lax+POST можно отключить в целях тестирования с помощью нового флага --enable-features=SameSiteDefaultChecksMethodRigorulous, чтобы разрешить тестирование сайтов и служб в конечном конечном состоянии функции, где смягчение снято. Дополнительную информацию см. в разделе Обновления SameSite для проектов Chromium
Тестирование в Chrome 80+
В Chrome 80 в консоли браузера появляются предупреждающие сообщения об отсутствии атрибутов sameSite. Нажмите F12, чтобы открыть консоль браузера.
Тест в Safari
Safari 12 строго реализует предыдущий проект и дает сбой, когда новое значение «Нет» находится в файле cookie. Ни один из них нельзя избежать с помощью кода обнаружения браузера. Поддержка старых браузеров в этом документе. Протестируйте вход в систему в стиле ОС на основе Safari 12, Safari 13 и WebKit, используя MSAL, ADAL или любую другую библиотеку, которую вы используете. Проблема зависит от базовой версии ОС. Известно, что OSX Mojave (10.14) и iOS 12 имеют проблемы совместимости с новым поведением SameSite. Обновление ОС до OSX Catalina (10.15) или iOS 13 устраняет проблему. Safari в настоящее время не имеет флага отказа для тестирования поведения новой спецификации.
Тест в Firefox
Поддержку нового стандарта в Firefox можно протестировать в версии 68+, включив ее на странице about:config с флагом функции network.cookie.sameSite.laxByDefault . Сообщений о проблемах совместимости со старыми версиями Firefox не поступало.
Тестирование в браузере Edge (устаревшей версии)
Edge поддерживает старый стандарт SameSite. Edge версии 44+ не имеет известных проблем совместимости с новым стандартом.
Тест с Edge (Chromium)
Тестирование с помощью Electron
Версии Electron включают старые версии Chromium. Например, версия Electron, используемая Teams, — это Chromium 66, которая демонстрирует более старое поведение. Вы должны выполнить собственное тестирование совместимости с версией Electron, которую использует ваш продукт. См. раздел Поддержка старых браузеров.
Отмена исправлений SameSite
Обновите web.config, чтобы включить следующие параметры конфигурации:
Примечание. Недавно стандарты, связанные с атрибутом Cookie SameSite, изменились следующим образом:
В этой статье описан новый стандарт. Информацию о конкретных версиях, в которых изменилось поведение, см. в разделе «Совместимость браузера» ниже.
Значения
Атрибут SameSite принимает три значения:
Файлы cookie не отправляются при обычных межсайтовых подзапросах (например, для загрузки изображений или фреймов на сторонний сайт), а отправляются, когда пользователь переходит на исходный сайт (т. е. при переходе по ссылке).
Это значение файла cookie по умолчанию, если SameSite не был явно указан в последних версиях браузера (см. функцию «SameSite: нестрогие значения по умолчанию» в разделе «Совместимость браузера»).
Примечание. Lax заменил None в качестве значения по умолчанию, чтобы обеспечить пользователям достаточно надежную защиту от некоторых классов атак с подделкой межсайтовых запросов (CSRF).
Строгий
Файлы cookie будут отправляться только в собственном контексте и не будут отправляться вместе с запросами, инициированными сторонними веб-сайтами.
Файлы cookie будут отправляться во всех контекстах, т. е. в ответах как на собственные запросы, так и на запросы из разных источников. Если установлено значение SameSite=None, также должен быть установлен атрибут безопасности файла cookie (иначе файл cookie будет заблокирован).
Исправление распространенных предупреждений
SameSite=Нет, требуется безопасный
В вашей консоли могут появиться предупреждения, подобные приведенным ниже:
Предупреждение появляется, потому что любой файл cookie, который запрашивает SameSite=None, но не помечен как безопасный, будет отклонен.
Примечание. В старых версиях браузера вы можете получить предупреждение о том, что файл cookie будет заблокирован в будущем. Например:
Файл cookie myCookie вскоре будет отклонен, так как для его атрибута SameSite задано значение None или недопустимое значение без безопасного атрибута.
Файлы cookie без SameSite по умолчанию имеют значение SameSite=Lax
Предупреждение появляется, потому что политика SameSite для файла cookie не была указана явно:
Вы должны явно сообщить предполагаемую политику SameSite для вашего файла cookie (вместо того, чтобы полагаться на то, что браузеры автоматически применяют SameSite=Lax). Это также улучшит взаимодействие с браузерами, поскольку не все из них по умолчанию используют Lax.
Пример
Технические характеристики
Совместимость с браузером
Таблицы BCD загружаются только в браузере
См. также
Нашли проблему с этой страницей?
Последнее изменение: 18 февраля 2022 г., авторы MDN
Ваш план улучшения Интернета.
Поддержка
Наши сообщества
Разработчики
Защитите свой сайт, проверьте, как видно отмечать межсайтовые файлы cookie.
Эта статья относится к циклу статей об изменениях в атрибуте Файлы cookie файлов SameSite:
Файлы cookieэто один из доступных методов добавления постоянного состояния веб-сайтов. С годами возможности cookie росли и развивались, но платформа сохранила часть прежних проблем. Для их решений (в том числе Chrome, Firefox и Edge) меняют свое поведение, чтобы больше восстановить параметры по умолчанию, сохраняя конфиденциальность.
Серверы требуют файлов cookie с помощью заголовка Set-Cookie .
Когда ваш читатель просматривает страницу, которая соответствует данному запросу, то есть просматривает в безопасности ограничения, а возраст cookie не превышает одного месяца, а пользователь отправил этот заголовок в своем запросе:
Браузер отправляет файл cookie обратно в заголовке Cookie .
Вы также можете добавлять и читать файлы cookie, доступные для этого сайта, в JavaScript, используя document.cookie . Запись в document.cookie при возникновении или переопределении файла cookie с этим ключом. Например, в консоли JavaScript можно попробовать установить следующее:
При чтении document.cookie будут выведены все файлы cookie, доступные в проверке, причем файл cookie разделен каждый раз с запятой:
JavaScript может получить доступ к файлу cookie с помощью document.cookie .
Если вы попробуете сделать это на некоторых популярных сайтах, вы заметите, что самое главное из них имеет значение трех файлов cookie. В большинстве случаев эти файлы cookie отправляются при каждом запросе к этому домену, который имеет ряд последствий. Пропускная способность обнаружения загрузки часто более ограничена, чем скорость загрузки для ваших пользователей, поэтому накладные расходы на все исходящие запросы требуют задержки до времени до первого байта. Необходимо учитывать выбор количества и размера файлов cookie, которые вы устанавливаете. использовать свойство Max-Age, чтобы достичь того, что файлы cookie не будут храниться долго необходимого.
Если вы вернетесь к значительной подборке сайтов, то, вероятно, заметите, что присутствуют файлы cookie для различных доменов, а не только для того, которые вы посещаете в данный момент. Файлы cookie, в том числе и в адресной строке браузера, указывают на наличие файлов cookie. Аналогично, файлы cookie из доменов, отличных от общих сайтов, окружены сторонними файлами cookie. Это определение не абсолютно, а зависит от контекста пользователя; Один и тот же файл cookie может быть как возник, так и находится посторонним, в зависимости от того, на каком сайте находится пользователь в данный момент. Файлы cookie начинаются с разных доменов на странице одной.
Пользователи также стали более осведомленными о том, как файлы cookie могут быть использованы на нескольких сайтах. Однако до сих пор пора не встречалось, что явно заявляют о своих намерениях в отношении файла cookie. Ваш файл cookie
promo_shown должен отправляться только как основной, тогда как сессионный cookie для просмотра, предназначенного для проникновения на другие сайты, намеренно предназначенного для обеспечения состояния выхода в систему в значительной степени.Ключевой термин
Ключевой термин
Если пользователь находится на your-project.github.io и запрашивает изображение с my-project.github.io , это межсайтовый запрос.
Введение атрибута SameSite в файл cookie предоставляет три различных типа управления этим поведением. Вы можете не использовать атрибут или использовать значение атрибута Strict или Lax, чтобы ограничить файлы cookie внутрисайтовыми запросами.
Если вы установите для атрибута SameSite значение Strict , ваш файл cookie будет отправляться только для внутренних сайтов. Говоря языком пользователей, файл cookie будет отправлен только в случае, если сайт для файла cookie предполагается с сайтом, который в данном моменте отображается в адресной строке. То есть, если файл cookie promo_show задан следующим образом:
Когда пользователь находится на следующем сайте, файл cookie будет отправлен вместе с запросом, как и ожидалось. Однако при переходе по ссылке на ваш сайт, например, с другого сайта или по электронной почте от друга, по первому запросу файл cookie не будет отправлен. Это хорошо, если файлы cookie относятся к функции, стоящей за начальной навигацией, например, сменой приобретения или совершением покупки, но слишком ограничивает promo_shown . Если ваш пользователь использовал ссылку на сайт, он хотел, чтобы файл cookie был отправлен, чтобы были применены предпочтения предпочтений.
Именно здесь и приходит на помощь SameSite=Lax , который разрешает доступ к навигации верхнего уровня. Давайте вернемся к приведенному выше примеру статьи о котике, где другой сайт Они предложили важную фотографию котика и предоставили ссылку на вашу оригинальную статью.
И файл cookie был задан следующим образом:
Когда читатель находится в блоге другого человека, файл cookie не будет отправлен, если запросит awesome-cat.jpg . Однако когда читатель перейдет по ссылке на cat.html в следующем блоге, этот запрос будет отображать файл cookie. Это делает значение Lax хорошим выбором для файлов cookie, влияющих на карту сайта, а значение Strict для файлов cookie соответствует с действиями пользователя.
Внимание
Ни Strict , ни Lax не закрывают полностью проблему с безопасностью. Файлы cookie отправляются как часть запроса пользователя, и вы должны выполняться к ним так же, как и к любому другому пользовательскому вводу. Это означает, что необходимо проверять и разрешать вводимые данные. Никогда не використовывайте файлы cookie для безопасного хранения данных на сервере.
Наконец, может быть недопустимым значением, которое ранее было способом неявного раскрытия тома, что вы хотите, чтобы файлы cookie отправлялись во всех контекстах. В последнем проекте RFC6265bis это делается явным путем указания нового значения SameSite=None . Это означает, что вы можете использовать значение None, чтобы четко указать, что вы намеренно хотите, чтобы файл cookie был отправлен в стороннем кабинете. Файлы cookie с явным представлением контекста None , Lax или Strict .
Если вы предоставляете услугу, потребляете другие сайты, например, виджеты, встроенный контент, партнерские программы, рекламу или вход на несколько сайтов, то вам следует использовать None , чтобы убедиться, что ваши намерения передают файлы cookie.
- если у файлов cookie не задан атрибут SameSite , будет считаться, что SameSite=Lax ;
- для файлов cookie с SameSite=None также требуется параметр Secure , что означает, что такой запрос должен приходить только по защищённому каналу.
Chrome реализует это поведение по умолчанию, с версией 84. В Firefox эти качества меняются в соответствии с нормами, ориентацией на Firefox 69, и в будущем они будут в РФ по умолчанию. Чтобы проверить это поведение в Firefox, в стране about:config и установите network.cookie.sameSite.laxByDefault . Эдж также изменил свое поведение по умолчанию.
Эта статья будет оценена по мере того, как дополнительные возможности объявят о поддержке.
Атрибут не задан
Если вы отправляете файл cookie без заданного значения для атрибута SameSite…
Применено поведение по умолчанию
Браузер будет обрабатывать этот файл cookie, как если бы было указано SameSite=Lax .
Хотя это и задумывалось о применении более безопасного значения по умолчанию, в идеале вам следует особо важное значение атрибута SameSite , а не запрашивается то, что применяет его за вас. Это делается намеренно в отношении использования файлов cookie в разных странах.
Внимание
Установка cookie без Secure будет отклонена.
Вы должны обязательно подтвердить, что значение для атрибута SameSite=None задан параметр Secure .
Убедитесь, что вы используете это действие для новых файлов cookie и храните файлы cookie, даже если срок их действия еще не истек.
Если вы полагаете, что какие-либо службы включают в себя внешний контент на следующем сайте, вам также следует уточнить у поставщика, обновите ли они свои службы. Возможно, вам потребуется восстановление зависимости или фрагменты кода, чтобы поддерживать сайт нового поведения.
Оба этих изменениях восстанавливаются с помощью факультативных версий, которые правильно реализовали предыдущую версию SameSite или просто не встречали его. Применяя эти изменения к своему файлу cookie, вы обнаруживаете недостоверность в их предполагаемом использовании, а не предполагаете поведения по умолчанию. Точно такие же любые клиенты, которые еще не распознают SameSite=None должны игнорировать его и выполнять работу, как если бы атрибуты не были установлены.
Предупреждение
Ряд версий, включая Chrome, Safari и UC, несовместимы с новым значением None и могут игнорировать или ограничивать файлы cookie. Это поведение исправлено в текущей версии, но вы должны проверить свой трафик, чтобы определить, какая доля пользователей обнаружена. Вы можете просмотреть список несовместимых клиентов на сайте Chromium.
Чтобы обнаружить подробнее том, как именно обновить файлы cookie для успешной обработки изменений SameSite=None и различия в поведении, достоверность статьи, Рецепты cookie SameSite.
Благодарим за вклад и отзывы Лили Чен, Мальте Убл, Майка Уэста, Роба Додсона, Тома Штайнера и Вивека Сехара.
Разработчики Chrome запускают новую модель в Chrome 80 в начале 2020 г. Mozilla и Microsoft также планируют ее последующую поддержку в Firefox и Edge, но у них они есть. Изменения в Chrome вступают в силу через несколько месяцев, однако разработчикам, которые используют файлы cookie, стоит начать подготовку к этому уже сейчас. Эта запись содержит сведения о ожидаемых изменениях. Подробные инструкции для создания сайта web.dev.
О файлах cookie для одного сайта или нескольких сайтов
На многих сайтах используются сторонние решения, например, теги рекламных сервисов, инструменты для подбора рекомендуемого трафика, виджеты (в том числе от социальных сетей) и т. д. п. Когда вы посещаете веб-страницы, эти сторонние сервисы собирают файлы cookie в будущем и впоследствии обращаются к ним, чтобы принять заданные пользователями сайты или проанализировать завершенность обсуждения. Каждый файл cookie относится к универсальному домену. Если этот домен соответствует стороннему сервису, а не сайту в адресной строке пользователя, то контекст файла обнаруживает файлы cookie для других, то есть такой файл, предназначенный для нескольких сайтов.
Менее очевидный пример – когда владелец нескольких сайтов использует для них один и тот же файл cookie. Несмотря на то, что сайты и файлы cookie принадлежат одному и тому же человеку, контекст все равно рассматривается сторонним, поскольку домен файла cookie не является наиболее популярным или уязвимым сайтом, который он использует.
Файл cookie внешнего контекста, если он предназначен для нескольких сайтов. Это может быть в ситуации, когда сторонняя веб-страница обращается к файлу cookie, который не относится к доменному ресурсу сайта.
Если же домен в адресной строке пользователя предполагается с доменом файла cookie, это называется собственным контекстом, то есть файл предназначен для одного сайта. Файлы cookie, обычно предназначенные для одного сайта, сохраняют, сохраняют данные о входе в систему, запоминают предпочтения пользователей и используют веб-аналитику.
Когда ресурс на веб-странице получает доступ к файлу cookie, связанному с доменом сайта, это называется собственным контекстом, то есть файл, предназначенный для одного сайта.
Новая безопасная и прозрачная модель обработки файлов cookie
Сегодня в случае, когда файл cookie предназначен только для использования в личных целях, разработчик может запретить внешний доступ к нему с помощью одной из настроек: SameSite=Lax или SameSite=Strict . Однако, поскольку далеко не все студенты пользуются этой рекомендацией, очень много файлов cookie даже в собственных специальностях по-прежнему подвергается угрозам, таким как подделка сайтов межсайтовых отправлений.
Помимо очевидных преимуществ с точки зрения безопасности, выявлено широкое распространение файлов cookie между сайтами, использующих большой трафик и возможность выбора. Например, файлы cookie, доступные только для одного сайта, независимо от межсайтовых файлов cookie.
Контроль в Chrome: с февраля 2020 г.
В случае Chrome 80, и система приема файлов cookie, для которых не задано значение SameSite, как файлы со значением SameSite=Lax . Сторонний доступ возможен только для файлов cookie с атрибутом Secure SameSite=None , что означает безопасное подключение. Средства включают в себя атрибуты SameSite=None и безопасные, доступные на платформе Chrome, будут рассматриваться с актуальной информацией о размещении.
Представители Mozilla подтвердили, что реализуют быструю модель защиты файлов cookie и намерены использовать группу " SameSite=None ; Secure" для файлов cookie межсайтовых файлов в Firefox. Компания Microsoft недавно сообщила о том, что готова использовать такую же модель. Эксперимент продолжается с Microsoft Edge 80.
Подготовка и возможная сложность
Если вы работаете с межсайтовыми файлами cookie, примените для их использования " SameSite=None ; Secure". У большинства не возникает сложностей с реализацией, но мы рекомендуем предварительно протестировать код, чтобы выявить тяжесть и трагические случаи. Примеры:
В статье об атрибутах SameSite, позволяющем управлять обработкой файлов cookie, вы найдете советы, которые помогут вам действовать в описанных выше правилах. Также, кто из вас узнал, кто часто сталкивается с вопросами по этой теме.
Если вы управляете только файлами cookie, предназначенными для одного сайта, вам не нужно будет ничего предпринимать. Chrome автоматически блокирует такие файлы cookie от внешнего доступа, даже если атрибут SameSite отсутствует или для него не задано значение. Однако мы рекомендуем вам добавить атрибута SameSite подходящего значения (Lax или Strict). Не предполагается, что это поведение по умолчанию, поскольку не во всех при этом работает защита файлов cookie с собственным контекстом.
Наконец, если вас интересует, готовы ли поставщики сервисов для сайта перейти на новую модель обработки файлов cookie, обратите внимание на поддержку в консоли Инструментов разработчика (Chrome версии 77 и более поздних). Если на странице есть межсайтовые файлы cookie, для которых не заданы параметры, вы увидите следующее:
Некоторые поставщики, в том числе выявленные сервисы Google, должны проводить постоянные изменения в течение нескольких месяцев до выхода Chrome 80 в ходе встречи. Вы можете связаться со своими участниками и узнать, готовы ли они.
Автор: Барб Палсер (Barb Palser), специалист по партнерству между Chrome и веб-платформами
Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.
Читайте также: