Как запретить meta - http-equiv="refresh"?

[Маэстро]

какого извините хрена эту проблему должен решать клиент?

laimas,
я написал свой вопрос на форум, чтобы услышать от специалистов ответ. Но разговор поворачивается таким образом, что я всё больше отвечаю на Ваши вопросы, а не получаю ответ.
Вы мыслите совершенно правильными классическими категориями, но... уже устаревшими. Известное правило "не доверять клиенту ни в чём" породило правило: "вся защита на сервере". А пробовали построить всю защиту на клиенте? имеется ввиду не при отправке данных на сервер, а при приёме. Я разработал такой механизм. Он перекрывает все известные мне уязвимости (их много). Но с "meta-refresh" есть проблемы (и то в частных случаях).
Не старайтесь понять зачем мне это надо. Старайтесь помочь, если можете.

[Маэстро]

Madzal,
это интересно.
В частности, что window.stop() останавливает загрузку окна, а не последующий выполняемый скрипт.
Простой тест показал положительный результат! Поисследую способ подробнее. Если будут какие-то неприятности - сообщу.
Спасибо!

[laimas]

Вы мыслите совершенно правильными классическими категориями, но... уже устаревшими.

Даже так, ну-ну, решайте вопросы безопасности исключительно на клиенте, оставляя сервер пассивным участником. Кошмар да и только.

я всё больше отвечаю на Ваши вопросы, а не получаю ответ.

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

[Маэстро]

...оставляя сервер пассивным участником...

А Вы думаете, что сервер решит все проблемы?? Наивно.
Вы предложили использовать htmlspecialchars . Это преобразует специальные символы в HTML-сущности. А мне не надо обезвредить ВСЕ html-теги, сделав их тупо видимыми. К тому же в тексте, отправляемом с сервера есть полезные html-теги, которые должны как положено отработать на клиенте.

Я ещё мог бы согласиться с Вами, если бы предложили использовать strip_tags (удаляет HTML и PHP-теги из строки).
Однако, из-за того, что strip_tags() не проверяет валидность HTML, то частичные или сломанные теги могут послужить удалением большего количества текста или данных, чем ожидалось! Просто говоря в некоторых случаях клиент увидит чистую страницу. И это плохо. Сам браузер лучше распарсит такой html, т.к. нет лучше "серверного парсера", чем сам браузер!
Предположим, что скоро разработчики PHP напишут более умный серверный парсер, но... дело в том, что этого мало.

На самом деле задача не просто обеспечить защиту на стороне клиента, а еще и сделать умный разбор html-тегов: распарсить все их атрибуты и все их свойства, проверить валидность и прочее. Назовите мне хотя бы 1 серверный парсер для этого?

И если Вы "консервант", то попробуйте решить такую задачку (на стороне сервера):
в html-коде найти все теги IMG, проверить их width и если ширина указана в px, то заменить width на "100%".

111111<img width="2000px" style="width:2000px" src=http://site.net/pic.jpg>222222

Получится? - Сниму шляпу!

вы же пионер-первопроходец, а я консервант, вот вы и маетесь дурью.

меня оскорбили? придурком обозвали?? Колумб тоже был первопроходец. он тоже маялся дурью. жаль в те времена серверов ещё не было.. а мог бы воспользоваться..

[laimas]

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

Вау, а браузер по вашему каким образом производит разбор строк, а входящий html-код, это строка, это потом ...? Он что использует нечто недоступное другим языкам? И серверу и совсем не нужна валидность тегов, для того чтобы некие из них запретить, да "умышленная невалидность" со стороны "вредителя" не в его пользу, если уж именно цель навредить.

Ну а то что "устаревшие понятия", то решить вопросы безопасности сервера без сервера, а веб приложение это сервер как не крути, нельзя, это объективность. А в случае описанном в данном посте, чему-то разрешить работать, то клиент вынужден постоянно парсить, анализировать, запрещать при каждой загрузке документа огромной армией пользователей, а делать это надо один раз при сохранении документа, но только более разумным, чем strip_tags, и средств для этого предостаточно. Уже с точки зрения нагрузки на клиента не разумно клиенту этим заниматься.

меня оскорбили? придурком обозвали??

Ни в коем случае, это мы все иногда делаем, я в том числе, либо недооценив, либо переоценив.

[Маэстро]

а браузер ... что использует нечто недоступное другим языкам?

ага. назовите аналогичную функцию парсинга в PHP?

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

ага. серверная функция "жадная". поэтому в процессе парсинга кромсает всё налево и направо, потому как в основе анализаторов заложен синтаксический поиск "уголков" <...>. браузер делает не так. он по мере возможности выбрасывает только невалидные теги (или их свойства).

...и средств для этого предостаточно (на сервере)

это голословно. Вы не привели никакой функции в качестве примера. и не смогли решить простую задачку про "IMG".

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

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

делать это надо один раз при сохранении документа (на сервере)

при параноидальной защите (т.е. очень хорошей) мы не имеем права полагаться ни на содержимое базы данных, ни на работу серверных скриптов (не стоит смеяться). поэтому последнее время к аксиоме "не стоит доверять клиенту" добавилась ещё одна: "не стоит доверять серверу". не слышали?

[Маэстро]

как вариант window.stop()

Исследовал данный подход в Google Chrome, FireFox и IE11. Оказывается разработчики браузеров по-разному трактуют stop.
Хорошая новость в том, что это работает и в Google Chrome и пресекает загрузку страницы, но не останавливает работу JS-скриптов (это хорошо).
Плохая новость: IE11 при window.stop() останавливает ВСЁЁЁ!

Подумываю об объединении варианта от Alexander Belov и Вашего вместе.. Вот только не хочется привязываться к конкретным браузерам. Это сейчас плохой тон. А то потом придется ещё рассматривать и разные версии этих браузеров..

[laimas]

ага. назовите аналогичную функцию парсинга в PHP?

Ага, а значит у браузера есть такая чудесная функция? Назвать можно? Вряд ли, ибо начало разбора строки, парсер, это только начало, а далее множество набора инструкций. А на сервере значит не доступно подобного, или думаете, что только на REGEXP пыхтеть?

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

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

это голословно. Вы не привели никакой функции в качестве примера.

Вам код написать или? Готового собственно полно, если интересует посмотреть.

и не смогли решить простую задачку про "IMG".

О какой IMG и задаче речь?

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

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

при параноидальной защите (т.е. очень хорошей) мы не имеем права полагаться ни на содержимое базы данных, ни на работу серверных скриптов (не стоит смеяться). поэтому последнее время к аксиоме "не стоит доверять клиенту" добавилась ещё одна: "не стоит доверять серверу". не слышали?

Хотите обижайтесь, хотите нет, но вы путаете хрен с пальцем.

[Маэстро]

мы с вами на разных полюсах. и от вас всё больше эмоций, а не конкретных строк js. поэтому дальше не вижу смысла спорить.
ладно, жизнь покажет кто прав.
p.s. а задачка про IMG в моем сообщении 12:15.

[laimas]

от вас всё больше эмоций, а не конкретных строк js

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

Про IMG, ага есть такое, и не говорите - задача для REGEXP коим обладает сервер, и который намного богаче REGEXP JS, просто неразрешимая.