Краткое содержание
Что меняется?
Начиная с Chrome 70, пользователи имеют возможность ограничить доступ к хосту расширений настраиваемым списком сайтов или настроить расширения так, чтобы для доступа к текущей странице требовался щелчок.
Какие API затронуты?
Это изменение затрагивает все API, на которые влияют разрешения хоста, указанные в манифесте вашего расширения, а также сценарии содержимого. API, требующие разрешений хоста, включают webRequest , cookie , tabs.executeScript() и tabs.insertCSS() , а также выполнение запросов между источниками, например, через API XMLHTTPRequest или fetch() .
Ограничение доступа
Как пользователь может ограничить доступ?
Пользователи могут разрешить запуск вашего расширения при нажатии, на определенном наборе сайтов или на всех запрошенных сайтах. Эти параметры представлены пользователям на странице chrome://extensions , а также в контекстном меню расширения.
Что произойдет, если пользователь решит запустить мое расширение «по клику»?
Расширение по существу ведет себя так, как если бы оно использовало разрешение activeTab . Расширению предоставляется временный доступ к любому хосту, на котором пользователь щелкает расширение, если этот хост был запрошен расширением (и не является сайтом с ограниченным доступом, например chrome://settings). Если Chrome настроен на запуск по щелчку мыши, Chrome помечает ваше расширение кружком и тенью (см. ниже), чтобы указать, что оно запрашивает доступ к определенному сайту.
Что произойдет, если пользователь решит запустить мое расширение на определенных сайтах?
Вашему расширению разрешено автоматически запускаться на любых сайтах, выбранных пользователем, и вы можете получить доступ к сайту без дальнейших действий пользователя. На других сайтах, которые запросило ваше расширение, но пользователь не предоставил разрешение, поведение такое же, как если бы пользователь настроил запуск расширения по щелчку мыши.
Что произойдет, если пользователь решит запустить мое расширение на всех сайтах?
Расширение может автоматически получать доступ к любым сайтам, запрошенным в манифесте.
Поведение API
API веб-запросов
Расширение по-прежнему может перехватывать, изменять и блокировать любые запросы от сайтов, к которым у него есть доступ. На сайтах, к которым расширение не имеет доступа, Chrome помечает расширение значком, указывающим, что расширение запрашивает доступ к странице. Затем пользователь может предоставить доступ к расширению; Затем Chrome предлагает пользователю обновить страницу, чтобы ваше расширение могло перехватывать сетевые запросы.
Скрипты контента, tabs.executeScript(), tabs.insertCSS()
Расширение по-прежнему может автоматически внедрять сценарии и таблицы стилей для любых сайтов, к которым у него есть доступ. На сайтах, к которым расширение не имеет доступа, Chrome помечает расширение значком, указывающим, что расширение запрашивает доступ к странице. Затем пользователь может предоставить доступ к расширению. Если сценарий содержимого настроен на вставку в document_idle, сценарий внедрит немедленно. В противном случае Chrome предложит пользователю обновить страницу, чтобы ваше расширение могло внедрить скрипты раньше при загрузке страницы (в document_start или document_end). Обратные вызовы для методов tabs.executeScript() и tabs.insertCSS() вызываются только в том случае, если пользователь предоставляет доступ к сайту.
Файлы cookie и фоновая страница XHR
Расширение по-прежнему может читать и изменять любые файлы cookie, а также выполнять XHR между источниками на сайтах, к которым у него есть доступ. Поскольку не существует вкладки, связанной со страницей расширения, осуществляющей доступ к файлам cookie другого источника или отправке XHR на другой хост, Chrome не маркирует расширение, чтобы указать пользователю, что расширение запрашивает доступ к сайту. Попытка получить доступ к файлу cookie для другого сайта или выполнить XHR для разных источников завершится ошибкой, как если бы манифест расширения не включал разрешение хоста. В этих случаях мы рекомендуем вам использовать дополнительные разрешения, чтобы позволить пользователю предоставлять доступ во время выполнения к различным сайтам.
Пример ниже иллюстрирует, как это может работать для API файлов cookie.
До:
{
...
"permissions": ["cookies", "https://example.com"]
}
chrome.cookies.get({url: 'https://example.com', name: 'mycookie'},
function(cookie) {
// Use the cookie.
});
После:
{
...
"permissions": ["cookies"],
"optional_permissions": ["https://example.com"]
}
// Note: permissions.request() requires a user gesture, so this
// may only be done in response to a user action.
chrome.permissions.request(
{origins: ['https://example.com']},
function(granted) {
if (granted) {
chrome.cookies.get({url: 'https://example.com', name: 'mycookie'},
function(cookie) {
// Use the cookie.
});
} else {
// Handle grant failure
}
});
Миграция
Каковы лучшие практики, позволяющие избежать негативного воздействия?
Расширения могут использовать дополнительные разрешения , API activeTab и declarativeContent , чтобы следовать рекомендациям. Дополнительные разрешения предоставляются во время выполнения и позволяют расширению запрашивать определенный доступ к сайту. Разрешение activeTab не затрагивается, и расширения, использующие его, продолжают работать нормально. API declarativeContent заменяет многие потребности по внедрению скриптов на каждую страницу.
Что произойдет с настройками моих текущих пользователей?
Это изменение не повлияет немедленно на текущие разрешения, предоставленные вашему расширению. То есть он будет продолжать работать как прежде, если пользователь не предпримет действия по ограничению сайтов, к которым ему разрешен доступ. В будущих выпусках Chrome предоставит пользователям больше возможностей для настройки параметров.
Как я могу проверить, есть ли у моего расширения разрешение на запуск на сайте?
Вы можете использовать API Permissions.contains() , чтобы проверить, предоставлен ли вашему расширению доступ к данному источнику.