Почему window (и unsafeWindow) не то же самое из userscript, что и из тега?
я столкнулся с проблемой при разработке этого малый userscript. Когда я хотел заблокировать каждый XMLHttpRequest
С запущенного сайта с моим скриптом ничего не происходило (по крайней мере, с Chrome):
function main() {
// Override XHR.open with a custom function
window.XMLHttpRequest.prototype.open = function() {
// Nothing... so it's supposed to block every xhr.open() call
}
}
main();
то же самое при замене window
by unsafeWindow
.
однако, когда я использовал этот трюк, все работало как шарм:
// No more call to main(), and:
var script = document.createElement("script");
script.textContent = "(" + main.toString() + ")();";
document.body.appendChild(script);
каждый вызов xhr.open
заменяется моей пользовательской функцией, не более АЯКС.
так что я думаю window
элемент не то же самое, когда main
вызывается из сценария, чем когда он вызывается из <script></script>
контейнер. Может кто-нибудь объяснить мне, почему ?
1 ответов
посмотреть " являются ли пользовательские скрипты Chrome отделены от глобального пространства имен, как скрипты Greasemonkey?". Как Chrome userscripts / content-scripts, так и скрипты Greasemonkey изолированы от javascript страницы. Это делается, чтобы помочь вам избежать взлома, но это также уменьшает конфликты и неожиданные побочные эффекты.
однако методы различны для каждого браузера...
Firefox:
- работает скрипты в песочница XPCNativeWrapper, если
@grant none
действует (начиная с GM 1.0). - по умолчанию обертывает скрипт в анонимную функцию.
- предоставляет
unsafeWindow
для доступа к javascript целевой страницы. Но будьте осторожны, что это возможно для враждебных веб-мастеров следоватьunsafeWindow
использование обратно в контекст скрипта и, таким образом, получить повышенные привилегии для pwn вас с.
Chrome:
- запускает скрипты в "изолированный мир".
- обертывает скрипт в анонимную функцию.
-
строго блокирует любой доступ к JS страницы скриптом и наоборот.
Последние версии Chrome теперь предоставляют объект с именемunsafeWindow
, для очень ограниченной совместимости, но этот объект не предоставляет никакого доступа к цели Пейдж Джей. Это то же самое, чтоwindow
в области сценария (которая не являетсяwindow
в контексте страницы).
что сказал, версия вашего скрипта, который использовал unsafeWindow
должен работать на / в Firefox, если реализован правильно. Это может работа с использованием в расширение Tampermonkey в на Chrome, но я не собираюсь перепроверять это прямо сейчас.
когда вы делаете это "фишка" (var script = document.createElement("script"); ...
), вы инъекции код на целевой странице. Это обходит песочницу и является единственным способом в обычном Chrome userscript для скрипта взаимодействовать с JS страницы.
укол плюсы:
- единственный способ для не-Tampermonkey userscripts для доступа к объектам или функциям, предоставляемым целевой страницы.
- почти всегда полностью совместим между Chrome, Firefox, Opera и т. д. (Т. е. есть, как всегда, что-то еще.)
- часто легче отлаживать весь скрипт; инструменты разработчика работают нормально.
укол недостатки:
скрипт, по крайней мере, введенные части, не может использовать расширенные привилегии (особенно междоменные), предоставляемые
GM_
функции -- особенноGM_xmlhttpRequest()
.
Обратите внимание, что в настоящее время Chrome поддерживает толькоGM_addStyle
,GM_xmlhttpRequest
,GM_log
иGM_openInTab
, полная, прирожденно.
Вы поддерживаетGM_
функции почти полностью, однако.может вызывать побочные эффекты или конфликты с JS страницы.
использование внешних библиотек создает еще больше конфликтов и проблем с синхронизацией. Это далеко не так просто, как
@require
.@require
, также запускает внешний JS из локальной копии -- ускорение выполнения и все, кроме устранения зависимости от внешнего сервер.страница может видеть, использовать, изменять или блокировать скрипт.
требует, чтобы JS был включен. Firefox Greasemonkey, особенно, может работать на странице, которая заблокирована JS. Это может быть находкой на раздутых, дерьмовых и / или навязчивых страницах.