Как должны сопоставляться URL-адреса из параметров пользователя в Content_Script?

Я пишу расширение с параметрами, которые позволяют пользователям решать, на каких сайтах они хотят, чтобы расширение работало.

Скажем, у пользователя есть этот сайт в настройках

site                          action
stackoverflow.com/*           change background css to blue
google.com/*                  change background css to green

Я сохраняю эту строку в файле options. Когда content_script запускается, должен ли я извлекать эти строки из параметров, перебирать каждую из них, анализировать с помощью urlParser на части, превращать каждую часть в регулярное выражение (избегая всего, кроме *) и сравнивать его с document.URL? Недавно я прочитал, что такая проверка пользовательских параметров для URL-адресов также должна выполняться с помощью фонового сценария, поэтому я не уверен, куда идти или есть ли более очевидный способ сделать это.

Я думаю, что такие расширения, как Adblocker и Vimium, имеют эту функциональность, но только для того, чтобы решать, на каких сайтах не работать. Я хочу выяснить, как решить, на каких сайтах будет работать.

Обновление вопроса: поскольку мой content_script должен запускаться в document_start (перед загрузкой страницы, поскольку он имеет дело с редактированием внешнего вида страницы) в качестве content_script, сможет ли фоновая страница выполнить content_script < strong>прежде чем веб-страница вообще загружается?


javascript google-chrome-extension
person irregular    schedule 30.09.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

URL-адрес проверенной веб-страницы должен быть «проверен» через фоновую страницу, поскольку параметры пользователя будут размещены в локальном хранилище в контексте фоновой страницы. Вот что я бы сделал... (хотя это скорее предложение, чем ответ).

Я не уверен, как действия в правом столбце вашего списка влияют на ваш вопрос, извините.

(Также обратите внимание, что вам потребуется включить библиотеку (внешнюю или самописную), которая может анализировать глобусы в регулярные выражения.)

manifest.json

permissions: ["tabs", "storage", "webRequest", "<all_urls>"]

background.js

//allow the webrequest to run on all urls
var filter = { urls: "<all_urls>" };

//receives url information from webrequest listener
function listen(details) {
    getUserOpts()
        .then(function(arrayOfWhitelistUrls) {
            //you can't use globs here, need to use more powerful filtering mechanisms
            if (arrayOfWhitelistUrls.indexOf(details.url) > -1) {
                message();
            }
        });
}

//returns a promise containing user defined whitelist urls from background local storage
function getUserOpts() {
    return new Promise(function(res, rej) {
        chrome.storage.get("whitelist", function(data) {
            //you are saving all localhost data as a string, so you need to parse it first
            res(JSON.parse(data));
        });
    });
}

//messages content script and allows execution
function message() {
    chrome.tabs.query({active: true}, function(tabs) {
        chrome.tabs.sendMessage(tabs[0].id, {permission: true});
    });
}

chrome.webRequest.onBeforeRequest.addListener(listen, filter)

contentscript.js

function listen(message) {        
    if (message.permission) {
        if (message.permission === true) {
            init();
        }
    }
}

//listen for message
chrome.runtime.onMessage.addEventListener(listen);

Таким образом, порядок, в котором все работает, выглядит следующим образом:

    1. background page listens to each web request
    1. on each web request, the background page asynchronously fetches user options from local storage
    1. if the url of the current tab passes your filter, message your content script
    1. the content script receives the message and then runs

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

person Daniel Lizik    schedule 30.09.2015
comment
Вместо этого вы можете вызвать chrome.tabs.executeScript на фоновой странице для запуска content_script. Часть действий была просто примером, я надеюсь делать более сложные вещи, чем изменение css. Меня больше всего беспокоит белый список пользователей, поэтому на данный момент кажется, что фоновая страница - это хорошая идея, чтобы не загружать весь контент_скрипт до тех пор, пока он не понадобится. - person irregular; 30.09.2015
comment
@user2807904 user2807904 это, вероятно, лучшее решение - person Daniel Lizik; 30.09.2015
comment
на самом деле я не уверен, завершится ли вызов фоновой страницы + content_script до загрузки страницы. Прямо сейчас мой content_script запускается в document_start, поэтому javascript завершает работу еще до загрузки страницы. (если вы поставите точку останова в content_script, браузер будет полностью белым и ничего не загружено. Будет ли то же самое для фонового скрипта или html будет загружаться во время работы background.js? - person irregular; 30.09.2015