JavaScript
Google Chrome
Comments 15
+1
Тема не раскрыта. Раньше доступ к скриптам страницы из контекста расширения был через использование небольшого костыля, но недавно эту уязвимость исправили.
0
Ну. Этот механизм не использует никакие уязвимости, всё законно. Правда, не удивлюсь, если в очередном обновлении Chrome запретит создавать элемент «script».
0
Это понятно, но по заголовку ожидал увидеть именно механизм прямого обращения расширения к JS сайта. Но похоже всё таки придётся переделывать своё расширение на общение через евенты.
+1
А как такового, доступа к окружению всё равно нет. Вы просто пропатчили функцию, которая записывает нужные данные в известные вам DOM-элементы.
Я в своё время реализовал доступ через custom events и listeners на DOM-элементах. Ибо модель DOM у страницы и скриптов расширений общая. Так даже весь объект window можно пробросить. И как раз такой способ советуют в developer.chrome.com.
-1
Да, я упомянул о том, что можно избавиться от промежуточных элементов, используя события. И, наверное, всегда лучше использовать этот механизм, но не обязательно же)
0
Серьёзно?
Очень странно. Заблочить то, что они сами предлагали в качестве примеров.
Вечером проверю.
0
Возможно я что-то делаю не совсем так, ибо подобных примеров не встречал в документации, а делал велосипед самостоятельно. Но суть в том, что раньше легко удавалось пробросить объект window из расширения на страницу сайта, и обратно, а сейчас, при попытке сделать тоже самое, возвращается свой window, а не чужой.
0
После обновления до 29-й версии действительно всё перестало работать. И это печально.
Кстати, они документацию поменяли. Теперь вместо эвентов советуют пользоваться postMessage. Для меня остаётся загадкой, как это работает. window ведь разные, по идее.
Подозреваю, что скоро могут прикрыть взаимодействие через эвенты…
-1
И в чем новизна вашего решения? Вы из таких скриптов всё равно не получите доступа к скриптам расширения.
+2
Решение известное и для опытных разработчиков очевидное, но, например, просто взять и найти его в гугле было нельзя. Почему бы его не задокументировать?
0
Да, должен работать везде и всегда. Проверял на последнем хроме под win и os x.
+1
Хм. Занятно. Я когда была была необходимость пропатчить из плагина процедуру на странице навелосипедил другой вариант:
В плагине весь патчер сворачивался в одну длинну-предлинную строку, в которой ссылка на оригинальный метод сохранялась в переменную, объявлялся прокси-метод с именем подменяемого, вызывающий как оригнальную процедуру так и «стучащий» об этом плагину через window.postMessage. А потом плагин успешно скармливал патчер странице заставив ее перейти по адресу «javascript:(function(){а_тут_идет_код_патчера_;})();». Слегка гемморойно сворачивать патчер в одну строчку, но зато обходило все ограничения по доступу без проблем.
0
Собственно к чему это я… А, вспомнил! По каким-то причинам из плагина создать элемент script не удавалось, уже и не вспомню по каким. А через location работало «на ура».
Only those users with full accounts are able to leave comments.  , please.