Вообще говоря предложенный по ссылке сценарий не является RCE уязвимостью — компьютер посетителя никто вообще не атакует. Flash в этом плане намного хуже — RCE уязвимости там находят с удручающей регулярностью. Наверное это и не удивительно, учитывая то с какими абсурдно высокими (для большинства решаемых флэшом задач) правами он обычно запускается в системе.
расстояние вот как раз перестает работать в случае появления какого-то устройства между картой и терминалом, а здравый смысл пасует если пользователь сам своими руками это устройство там разместил
я бы на вашем месте всерьез задумался над какой-то профильной сертификацией, если вы хотите свое устройство внедрять
Сейчас уже известно, что айпэды, смартфон и иксбоксы являются одной из форм цифрового наркотика. Недавние исследования сканиов мозга показывают, что они влияют на лобную долю коры головного мозга – контролирующую дофаминовую систему, отвечающую за вознаграждения, внимание, кратковременную память – точно так же, как кокаин.
Я по роду деятельности провожу по 8 часов в день за «экраном», если мои ощущения после рабочего дня такие же как от приема «веществ» то не понимаю ради чего наркоманы их потребляют.
Или автор считает что у этих «айпэдов, смартфонов и иксбоксов» экраны чем-то принципиально отличаются от моего рабочего ЖК монитора?
Или, о ужас, дело таки не в конкретных устройствах как таковых?
Aptana Studio выглядит весьма мертвой в данный момент — последняя версия выходила 31 июля 2014, последнее сообщение в твиттере 1 декабря 2014. Для Eclipse я бы сейчас стал смотреть в сторону Webclipse, WTP или Tern Eclipse IDE
Вы навели меня на интересную мысль: зачем вообще base64, если css это не бинарный формат а текстовый? В соответствии со спецификацией dataURL можно написать так:
link.href = "data:text/css,"+encodeURI(cssText);
Затраты на кодирование это не отменяет, но проблемы с символами вне Latin1 должно решить.
В статье по вашей ссылке для создания новой таблицы стилей, куда потом складываются правила, используется тэг style. Я бы хотел этого избежать, т.к. хочется задавать наиболее общие стили, которые при необходимости можно было наибольшим числом способов переопределить/изменить.
Я бы не стал говорить о преимуществе данного метода перед Require-css, это просто интересный (как мне показалось) способ включения css стиля в страницу. Если все же сравнивать два метода, то в ветке выше я высказал предположение, что при определенных настройках плагина будут проблемы в модуле, после обработки оптимизатором. С другой стороны у описанного в статье метода проблемы из-за base64 вцелом (как минимум избыточная трата ресурсов на перекодирование), и в реализации функции-кодировщика в частности.
Для постоянного применения я бы данный метод советовать не стал, но в определенных условиях способ может иметь преимущества (например в простоте: реализация занимает меньше 15 строчек, а ради какого-то модуля в проекте и css-ки из 2-х строк может незахотеться тащить плагин)
т.е. в url всегда оказывается именно адрес css файла, а значит
var link = document.createElement('link');
link.type = 'text/css';
link.rel = 'stylesheet';
...
link.href = url;
head.appendChild(link);
будет именно вставлять элемент с обычным URL, а не DataURL как в моем случае. Я не вижу варианта как при исполнении такого кода браузер смог бы обойтись без отправки запроса на получение указанного css файла (или обращения к кэшу, что в данном случае не играет роли — положить в кэш браузера содержимое css-файла из JS кода мне не представляется выполнимым)
Спасибо за ссылку, выборочно посмотрел (вступление, и про css). Честно говоря не понравилось: если в двух словах то для моих задач выглядит огромным оверкиллом. Я бы даже рискнул сказать что судя по тому что я успел посмотреть RequireJS и Webpack немного для разного нужны. Мне кажется было бы корректнее сравнивать r.js и Webpack.
В общем после поверхностного знакомства осталось ощущения как от сравнения подходов написания инструментов под *nix и Windows, в одном случае минималистичность и «единственное предназначение», а в другом «умеем все» но как-то неаккуратно, исходники даже без минимайзера после упаковки выглядят совсем не так как проект при разработке, какие-то свои сложные внутренние абстракции типа цепочек загрузчиков с pitch функциями и т.д.
P.s. остался вопрос, а если у меня в названии какого-то файла в модуле или каталога присутствует символ "!" или даже 2 идущих подряд, то сборка не сломается?
var linkLoad = function(url, callback) {
var link = document.createElement('link');
link.type = 'text/css';
link.rel = 'stylesheet';
if (useOnload)
link.onload = function() {
link.onload = function() {};
// for style dimensions queries, a short delay can still be necessary
setTimeout(callback, 7);
}
else
var loadInterval = setInterval(function() {
for (var i = 0; i < document.styleSheets.length; i++) {
var sheet = document.styleSheets[i];
if (sheet.href == link.href) {
clearInterval(loadInterval);
return callback();
}
}
}, 10);
link.href = url;
head.appendChild(link);
}
т.е. если мы хотим получить именно link, то он подставляет url в тэг и тем или иным способом проверяет что загрузка завершена, вопрос в том, что произойдет если я минифицировал и у паковал исходники, и указанный файл уже на самом деле изначально выгружен браузеру
я что-то давно не слышал об уязвимостях класса RCE для JS движков популярных браузеров, хотя возможно просто не следил
расстояние вот как раз перестает работать в случае появления какого-то устройства между картой и терминалом, а здравый смысл пасует если пользователь сам своими руками это устройство там разместил
я бы на вашем месте всерьез задумался над какой-то профильной сертификацией, если вы хотите свое устройство внедрять
Я по роду деятельности провожу по 8 часов в день за «экраном», если мои ощущения после рабочего дня такие же как от приема «веществ» то не понимаю ради чего наркоманы их потребляют.
Или автор считает что у этих «айпэдов, смартфонов и иксбоксов» экраны чем-то принципиально отличаются от моего рабочего ЖК монитора?
Или, о ужас, дело таки не в конкретных устройствах как таковых?
показывает обратное: body красный.
Затраты на кодирование это не отменяет, но проблемы с символами вне Latin1 должно решить.
Для постоянного применения я бы данный метод советовать не стал, но в определенных условиях способ может иметь преимущества (например в простоте: реализация занимает меньше 15 строчек, а ради какого-то модуля в проекте и css-ки из 2-х строк может незахотеться тащить плагин)
т.е. в url всегда оказывается именно адрес css файла, а значит
будет именно вставлять элемент с обычным URL, а не DataURL как в моем случае. Я не вижу варианта как при исполнении такого кода браузер смог бы обойтись без отправки запроса на получение указанного css файла (или обращения к кэшу, что в данном случае не играет роли — положить в кэш браузера содержимое css-файла из JS кода мне не представляется выполнимым)
В общем после поверхностного знакомства осталось ощущения как от сравнения подходов написания инструментов под *nix и Windows, в одном случае минималистичность и «единственное предназначение», а в другом «умеем все» но как-то неаккуратно, исходники даже без минимайзера после упаковки выглядят совсем не так как проект при разработке, какие-то свои сложные внутренние абстракции типа цепочек загрузчиков с pitch функциями и т.д.
P.s. остался вопрос, а если у меня в названии какого-то файла в модуле или каталога присутствует символ "!" или даже 2 идущих подряд, то сборка не сломается?
т.е. если мы хотим получить именно link, то он подставляет url в тэг и тем или иным способом проверяет что загрузка завершена, вопрос в том, что произойдет если я минифицировал и у паковал исходники, и указанный файл уже на самом деле изначально выгружен браузеру