Коротка відповідь
Необов’язкові дозволи дають змогу ввімкнути функцію, коли зрозуміла причина доступу. Оголосіть можливість у маніфесті, запросіть вузький фактичний дозвіл через дію користувача та підтримуйте відмову. Налаштування autoInspect: true не доводить, що Chrome досі надає доступ. Перевіряйте поточний стан через API дозволів.
Посібник зосереджений на інтерфейсі та життєвому циклі згоди. Для одноразової перевірки після запуску використовуйте activeTab; для постійної функції на сайті — необов’язковий host-доступ. Необов’язковість не виправдовує надмірний запит, і не кожен дозвіл браузера підтримує таке оголошення.
Практичні кроки реалізації
Поясніть функцію перед запитом
Розмістіть елемент поруч із функцією, наприклад «Увімкнути автоматичну перевірку на app.example.com». Поясніть читання даних, локальність і вимкнення. Не ховайте запит за загальним «Зберегти» та не додавайте непов’язані можливості. Узгодьте текст продукту з браузерним запитом, не вдаючи, що керуєте текстом попередження.
Запитуйте всередині взаємодії
Підготуйте потрібний origin до обробника натискання. Викличте permissions.request прямо з нього, потім обробіть результат. Стороння асинхронна підготовка перед запитом може порушити вимогу user gesture. Boolean показує, чи надано доступ; виняток — окремий збій, а не інша назва відмови. Показуйте ці стани окремо.
Розділіть намір і можливість
Прапорець виражає бажаний стан функції. Дозвіл Chrome визначає поточну можливість. Зберігайте намір після успішного запиту; фактичний стан залежить від наміру й поточних дозволів. Слухайте зміни та оновлюйте відкриті інтерфейси. Дозвіл може існувати при вимкненій функції, а налаштування — після відкликання. Жоден стан не повинен давати оманливе «увімкнено».
Узгодьте реєстрації та збережені дані
Якщо дозвіл реєструє динамічний скрипт, відкликання має узгодити реєстрацію та зупинити майбутню роботу. Скасування реєстрації не прибирає вже ін’єктований код чи UI. За потреби додайте очищення інтерфейсу. Відкликання також не видаляє локальну колекцію автоматично. Дайте окреме видалення та поясніть різницю дій.
Приклад реалізації
Приклад передбачає сторінку налаштувань із кнопкою enable-site та елементом site-status. Він запитує один оголошений host. Для довільних сайтів оголосіть відповідну необов’язкову межу та обчисліть точний origin із перевірених даних до натискання. Приклад не реалізує реєстрацію скриптів.
{
"manifest_version": 3,
"name": "Optional site example",
"version": "1.0.0",
"optional_host_permissions": ["https://app.example.com/*"]
}
const grant = { origins: ["https://app.example.com/*"] };
const button = document.querySelector("#enable-site");
const status = document.querySelector("#site-status");
button.addEventListener("click", async () => {
try {
const accepted = await chrome.permissions.request(grant);
status.textContent = accepted ? "Site access enabled" : "Access was not granted";
} catch {
status.textContent = "Could not request site access";
}
});
chrome.permissions.onRemoved.addListener(async () => {
const available = await chrome.permissions.contains(grant);
status.textContent = available ? "Site access enabled" : "Site access unavailable";
});
У повній функції блокуйтесь від повторних натискань під час запиту й ініціалізуйте UI через contains. Перед привілейованою роботою повторно перевіряйте доступ і обробляйте збій: дозвіл може змінитися між перевіркою та використанням. Джерелом істини є браузерний дозвіл, а не кешований Boolean.
Компроміси та альтернативи
Обов’язковий доступ доречний для основної мети продукту; необов’язковий — для доповнень, які можна вимкнути. Поділ функції на безліч дрібних запитів може заплутати більше за один узгоджений запит. Групуйте можливості лише для тієї самої поясненої операції та зберігайте придатність продукту без доповнення.
Описана ручна перевірка Font Picker корисна для порівняння тимчасового доступу з запропонованим автоматичним режимом. Опис не підтверджує існування такого режиму. Постійна перевірка є окремою пропозицією, яка потребує дозволів, опису приватності та обробки відмов.
Поширені помилки
- Повторний запит під час кожного відкриття після відмови.
- Сприйняття необов’язкового оголошення як чинного дозволу.
- Збереження ввімкненого стану до завершення запиту.
- Забуті реєстрації та ін’єктований UI після зміни доступу.
- Припущення, що відкликання видаляє збережені дані.
Контрольний список перед випуском
- Запит відбувається після явно підписаної дії.
- Запитані origin не ширші за оголошену межу.
- Відмова, виняток і відкликання мають окремі стани.
- Налаштування читають поточні дозволи.
- Реєстрація та очищення UI відповідають фактичному стану.
- Відкликання й видалення даних пояснено окремо.
Поширені запитання
Чи кожен дозвіл може бути необов’язковим?
Ні. Перевірте винятки поточного довідника до проєктування UI. Для функції з непідтримуваним необов’язковим дозволом потрібна інша можливість або обов’язковий дозвіл. Не обіцяйте запит, якого платформа не підтримує.
Чи додавання необов’язкового дозволу вмикає його користувачам?
Ні. Це оголошує можливість запиту. Користувач має ввімкнути відповідну функцію та надати доступ. Типовий стан повинен відповідати відсутності дозволу.
Чи має відмова блокувати все розширення?
Зазвичай необов’язкова функція лишається вимкненою, а незалежні працюють. Якщо без дозволу немає корисної поведінки, перегляньте його необов’язковість та чесно поясніть основну вимогу продукту.
Висновок
Проєктуйте згоду як машину станів: недоступно, запит, надано, відмовлено, відкликано. Фактична поведінка залежить від дозволів і наміру; явно узгоджуйте ін’єктовану роботу та збережені дані. Зрозуміле відкликання — частина функції, а не додаток до кнопки запиту.
Первинні джерела
Пов’язані посібники та приклади
Потрібно реалізувати це у вашому продукті?
Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.