Pull to refresh

Comments 73

Вроде jQuery давненько умеет такое, достаточно добавить в конец запроса "?" и все сработает.
Только не понимаю такой реакции на это.
В статье речь идет о кроссдоменных POST запросах. Кроссдоменный GET может в jQuery и есть (и скорее всего реализуется через элемент script).
Скорее всего вы думаете про JSONP.
промахнулся кнопкой, этот комментарий относительно первого комментария akira
у iframe style="display:none" дважды идет…

а так — молодцы, что еще сказать :)
да, точно, механическая ошибка :)… спасибо.
в избранное! Спасибо, будет полезно :)
а че минусуте человека :), согласен — звучит клево! да и название запоминающееся :). на самом деле это аббревиатура.
> Суть реализации XSS POST основана на особенностях хранения данных в свойстве window.name.
мм? sessvars основаны на этом же самом факте.
и что? непонятно как указанная вами статья коррелируется с текущей. вы бы хоть чтото словами добавили, а то непонятно зачем тут эта ссылка
Просто похожая статья, похожий метод, похожие идеи. Так, к размышлению.
ну так бы и написали :). да, ваша статья тоже очень интересна и я пользуюсь таким подходом в своих приложениях, и другим советую.
Собственно, да — об этом писали ещё в мае.
О кроссдоменном POST?
О ключевом механизме этой кроссдоменности.
Механизм то ключевой, но о том что можно сделать альтернативу XMLHttpRequest где будет реализация HTTP методов GET и POST в той статье даже и намека не было.
Да я не против — познавательно, по-человечески написано.
Просто подтвердил для тех, кто в шоке, что про window.name уже крики были.
а у меня почемуто не получилось считать window.name из одного окна, установив его в другом
точнее нигде кроме експлорера не видно. версии последние
Да и аватар у вас не грузится… )
блин. только заметил. да шо ж это такое? не грузится ничего… а если серьезно где я не прав?
window.name распространяется на одну и туже вкладку в одном и том же окне
А не лучше ли кросс-доменные AJAX запросы делать через «прокси»-скрипт на сервере? Это к тому же позволяет контролировать в одном месте все проходящие запросы (например, в целях предотвращения уязвимостей).
не всегда, есть случаи когда XSS POST жизненно необходим. Судить лучше или хуже надо в конкретной ситуации относительно конкретно решаемой задачи.
К примеру возьмите тотже Google AJAX Language API — вам было бы удобно ставить к себе прокси?
Ну не знаю как Гугл АПИ, не пользовался, но прокси-скрипт имеет и свои преимущества, все таки создавать ифреймы, сабмитить туда формы — очень извратно… что-ли. По моему, это явно неправильный способ, и кросс-доменные запросы не зря ограничиваются браузером.
не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами — вряд ли это поведение описано в каком-нибудь стандарте, и уже сейчас вряд ли оно будет работать в хроме (его разработчики вроде обещали полностью очищать все данные при смене домена)

а насколько я понял по описанию принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных. Кстати, имхо именно по причине древности «это событие прошло незамеченным»
1) >принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных

принцип работы dojo такой же как и у нас. мы используя тот же подход сделали другим образом (другая реализация).
2) >не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами
сохраняется 100%

3) >вряд ли оно будет работать в хроме
почему не проверили? работает 100%

4) > Кстати, имхо именно по причине древности «это событие прошло незамеченным»
кстати как раз этого и достаточно чтобы «дожить» до нормальной реализации XDomain, которая заложена в новых стандартах W3ORG
Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате, поэтому это закрывать не будут, а если и будут то уже в спецификации HTML5 предусмотрены функции для кроссдоменного доступа и это работает уже в FF3. Остальные браузеры поднятнутся. Зачем это нужно? Покажут новые проекты.
гыгыгы, «определённый формат» % )
security through obscurity, да? Если да, то не позорьтесь: )
Вы бы термины не применяли в которых не разбираетесь ;)

Формат ответа window.name=’данные’ не для того чтобы запутать злоумышленника, а для того чтобы наоборот открыть данные для кроссдоменных запросов. Так что сами не позорьтесь.
окей, давайте разберёмся, кто чего не понимает

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

кроме того, вы говорите «Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате». В мире компьютерной безопасности это означает, что безопасность обеспечивается исключительно тем, что злоумышленник не знает формата, в котором передаются данные. Именно такой подход называется security through obscurity, и именно его ругают все подряд.
Нету задачи запутать злоумышленника. Стоит задача дать возможность кроссдоменных запросов для чистых JavaScript решений. Решается эта задача через хак — window.name транспорт. Есть еще одно решение через script транспорт. Оба хака не нарушают философию Same Origin Policy (изоляция сайта в пределах протокола, домена и порта) иначе бы их прикрыли. Потомучто для обоих хаков скрипты на которые производится кроссдоменный запрос изначально разрабатываются с поддержкой этих транспортов.

хм, если нет задачи запутать злоумышленника, почему вы вообще начали говорить про безопасность?
Потомучто кроссдоменные запросы запрещены из-за соображений безопасности, и чтобы делать такие запросы приходится пользоваться хаками, но они не нарушают принцип Same Origin Policy. Поэтому вероятность что закроют хаки низка.
ага, спасибо за разъяснение, теперь понятно лучше, чем из первого вашего комментария. Он всё-таки больше напоминал о подходе «никто не знает, какой у меня алгоритм»: )
потому что данный подход хоть и позволяет осуществлять кросс-доменные запросы в это же время не позволяет производить XSS скрабинг или как он называется по модному «Фишинг»
пусть не позволяет, ладно

но я уверен, что к первому моему комментарию такая реплика не имела отношения; )
про принцип работы я ошибся, да. Удивлён, что они стали так заморачиваться.

фраза «100% сохраняется/работает» верна *на текущий момент* в тех браузерах, *которые вы тестировали*. Это может сломаться в ближайшем будущем, или не работать в редком браузере.

а поддержки нового клёвого стандарта ждать долго: (
пока вы ждете и фантазируете на тему «как все плохо» — мы делаем нужные вещи и делимся с другими. Тех браузеров в которых мы тестировали достаточно с головой, потому что они перекрывают 95-99% pageview.
> пока вы ждете и фантазируете на тему «как все плохо»

классический, но от этого не менее смелый ход в дискуссии — обвинить собеседника в только что придуманном грехе: )

> достаточно с головой, потому что они перекрывают 95-99% pageview

у меня большой опыт попадания в оставшиеся 1-5%, поэтому я и рекомендую использовать стандартные подходы
> у меня большой опыт попадания в оставшиеся 1-5%

это как понимать? что у вас не работает наша тестовая страница?
сейчас ваша тестовая страница у меня работает. Но я не уверен, что так оно будет и дальше
а я не уверен что интрнет вообще будет дальше работать и что? я ж написал в начале
фантазируете на тему «как МОЖЕТ БЫТЬ все плохо» когда в настоящий момент хорошо :)
а я уверен, что дальше интернет будет работать. Потому что он основан на открытых стандартах, которые может поддерживать любой человек. А полуслучайные совпадения, которые не описаны ни в каком публичном документе, могут внезапно исчезнуть, как уже не раз бывало. Недавно, например, закончилась поддержка Flash Paper, и никто ничего с этим не может поделать
Начет закрытия хаков врятли они так поступят. Например, альтернатива window name хаку есть script. Известно что через тег script можно загружать скрипты с любого домена. Причем эта поддержка на уровне стандарта. Хак заключается в том что нужно вернуть валидный js код, а там уже будет содержаться ответ от сервера, например ответ от сервера такой, а клиентский код уже содержит функцию my_callback которая получит в аргументе ответ.

Чтобы прикрыть этот хак нужно запретить загрузку скриптов с другого домена. А это уже изменение на уровне стандарта. А если просто взять и запретить загрузку скриптов с другого домена может перестать работать множество сайтов (кто его знает сколько таких сайтов в сети, например у гугли есть целый сервис, который предоставляет скрипты популярных фреймворков, чтобы разработчики не хранили их у себя, а могли загрузить их с серверов гугли).
P.S. > например ответ от сервера такой <скрипт>my_callback('тут ответ в формате XML и т. п.')</скрипт>
оно понятно, что скрипты с другого домена будут работать как раньше. Вопрос только — при чем здесь window.name? Все эти аргументы к нему неприменимы.
Потомучто если будут закрывать window.name тогда надо и закрыть возможность получить кроссдоменные данные через script. Иначе одно закрыли, а другое нет, поэтому не будут трогать ни то ни другое.
нет уж, извините
вы сами сказали, что поведение script в спеке прописано (не хак), а поведение window.name — нет (хак). Именно поэтому первое не закроют, а второе могут закрыть.
а смысл? я не думаю что браузеры разрабатывают неумные люди, делают такие же програмеры как и мы, опасности в window.name нету значит и смысла закрывать нету, иначе уже б давно закрыли.
бывает, находят новые уязвимости, о которых не знали раньше
ну относительно window.name на данній момент уязвимости нет. если найдете — напишите статью, интересно будет почитать, я вам подкину пару вопросов, да и покритикую с удовольствием :)
да, сейчас нет

я изначально говорил именно о свойстве future-proof, которым стандартизованные вещи обладают в гораздо большей степени, чем подобные хаки
UFO just landed and posted this here
Вам наверно сюда: tema.livejournal.com
UFO just landed and posted this here
Что-то мне подсказывает что туда идти не следует))) Да и нет привычки кликать по всем ссылкам)

Может вам аналогичную ссылку на lleo подкинуть?
UFO just landed and posted this here
Очень сильно извиняюсь, но я реализовывал динамический script по долгу службы еще прошлой осенью… в сентябре. Да и раньше это было и работало… и механизм с iFrame тогда существовал и работал…
м? чего в этом нового? обертка в класс? хаафо, только были уже jQuery плагины для этого.
хорошо что извеняетесь :), потому что вы не внимательно прочитали даже заголовок — POST, основная соль в этом
* перечитывает… клепает тест… * о_О
и правда. спать надо больше…
не зря извинился) пардон.
Автору огромный респект, за обзор решения подобной проблемы, второй день парюсь с подобной проблемой
автору спасибо, помогла схема.
Заметил одну такую особенность…
если в срипте убрать вот эту строчку
finish[id] = callback;
то сервер на который отправляется запрос начинает изрядно подвисать.

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

2 раза запускал скрипт, и два раза на тот сайт становилось тяжело пробиться, возможно хостинг как то не адекватно реагировал… ну или в этот момент срабатывал чей-нибудь злой ддос ^)
уверен что проблема никак не связана с finish[id] = callback;
Sign up to leave a comment.

Articles