Механизм то ключевой, но о том что можно сделать альтернативу XMLHttpRequest где будет реализация HTTP методов GET и POST в той статье даже и намека не было.
А не лучше ли кросс-доменные AJAX запросы делать через «прокси»-скрипт на сервере? Это к тому же позволяет контролировать в одном месте все проходящие запросы (например, в целях предотвращения уязвимостей).
не всегда, есть случаи когда XSS POST жизненно необходим. Судить лучше или хуже надо в конкретной ситуации относительно конкретно решаемой задачи.
К примеру возьмите тотже Google AJAX Language API — вам было бы удобно ставить к себе прокси?
Ну не знаю как Гугл АПИ, не пользовался, но прокси-скрипт имеет и свои преимущества, все таки создавать ифреймы, сабмитить туда формы — очень извратно… что-ли. По моему, это явно неправильный способ, и кросс-доменные запросы не зря ограничиваются браузером.
не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами — вряд ли это поведение описано в каком-нибудь стандарте, и уже сейчас вряд ли оно будет работать в хроме (его разработчики вроде обещали полностью очищать все данные при смене домена)
а насколько я понял по описанию принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных. Кстати, имхо именно по причине древности «это событие прошло незамеченным»
1) >принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных
принцип работы dojo такой же как и у нас. мы используя тот же подход сделали другим образом (другая реализация).
2) >не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами
сохраняется 100%
3) >вряд ли оно будет работать в хроме
почему не проверили? работает 100%
4) > Кстати, имхо именно по причине древности «это событие прошло незамеченным»
кстати как раз этого и достаточно чтобы «дожить» до нормальной реализации XDomain, которая заложена в новых стандартах W3ORG
Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате, поэтому это закрывать не будут, а если и будут то уже в спецификации HTML5 предусмотрены функции для кроссдоменного доступа и это работает уже в FF3. Остальные браузеры поднятнутся. Зачем это нужно? Покажут новые проекты.
Вы бы термины не применяли в которых не разбираетесь ;)
Формат ответа window.name=’данные’ не для того чтобы запутать злоумышленника, а для того чтобы наоборот открыть данные для кроссдоменных запросов. Так что сами не позорьтесь.
сначала вы говорите про безопасность. Потом вы говорите, что это не для безопасности, а наоборот. Меня это удивляет, мягко говоря
кроме того, вы говорите «Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате». В мире компьютерной безопасности это означает, что безопасность обеспечивается исключительно тем, что злоумышленник не знает формата, в котором передаются данные. Именно такой подход называется security through obscurity, и именно его ругают все подряд.
Нету задачи запутать злоумышленника. Стоит задача дать возможность кроссдоменных запросов для чистых JavaScript решений. Решается эта задача через хак — window.name транспорт. Есть еще одно решение через script транспорт. Оба хака не нарушают философию Same Origin Policy (изоляция сайта в пределах протокола, домена и порта) иначе бы их прикрыли. Потомучто для обоих хаков скрипты на которые производится кроссдоменный запрос изначально разрабатываются с поддержкой этих транспортов.
Потомучто кроссдоменные запросы запрещены из-за соображений безопасности, и чтобы делать такие запросы приходится пользоваться хаками, но они не нарушают принцип Same Origin Policy. Поэтому вероятность что закроют хаки низка.
ага, спасибо за разъяснение, теперь понятно лучше, чем из первого вашего комментария. Он всё-таки больше напоминал о подходе «никто не знает, какой у меня алгоритм»: )
потому что данный подход хоть и позволяет осуществлять кросс-доменные запросы в это же время не позволяет производить XSS скрабинг или как он называется по модному «Фишинг»
про принцип работы я ошибся, да. Удивлён, что они стали так заморачиваться.
фраза «100% сохраняется/работает» верна *на текущий момент* в тех браузерах, *которые вы тестировали*. Это может сломаться в ближайшем будущем, или не работать в редком браузере.
а поддержки нового клёвого стандарта ждать долго: (
пока вы ждете и фантазируете на тему «как все плохо» — мы делаем нужные вещи и делимся с другими. Тех браузеров в которых мы тестировали достаточно с головой, потому что они перекрывают 95-99% pageview.
а я не уверен что интрнет вообще будет дальше работать и что? я ж написал в начале
фантазируете на тему «как МОЖЕТ БЫТЬ все плохо» когда в настоящий момент хорошо :)
а я уверен, что дальше интернет будет работать. Потому что он основан на открытых стандартах, которые может поддерживать любой человек. А полуслучайные совпадения, которые не описаны ни в каком публичном документе, могут внезапно исчезнуть, как уже не раз бывало. Недавно, например, закончилась поддержка Flash Paper, и никто ничего с этим не может поделать
Начет закрытия хаков врятли они так поступят. Например, альтернатива window name хаку есть script. Известно что через тег script можно загружать скрипты с любого домена. Причем эта поддержка на уровне стандарта. Хак заключается в том что нужно вернуть валидный js код, а там уже будет содержаться ответ от сервера, например ответ от сервера такой, а клиентский код уже содержит функцию my_callback которая получит в аргументе ответ.
Чтобы прикрыть этот хак нужно запретить загрузку скриптов с другого домена. А это уже изменение на уровне стандарта. А если просто взять и запретить загрузку скриптов с другого домена может перестать работать множество сайтов (кто его знает сколько таких сайтов в сети, например у гугли есть целый сервис, который предоставляет скрипты популярных фреймворков, чтобы разработчики не хранили их у себя, а могли загрузить их с серверов гугли).
Потомучто если будут закрывать window.name тогда надо и закрыть возможность получить кроссдоменные данные через script. Иначе одно закрыли, а другое нет, поэтому не будут трогать ни то ни другое.
нет уж, извините
вы сами сказали, что поведение script в спеке прописано (не хак), а поведение window.name — нет (хак). Именно поэтому первое не закроют, а второе могут закрыть.
а смысл? я не думаю что браузеры разрабатывают неумные люди, делают такие же програмеры как и мы, опасности в window.name нету значит и смысла закрывать нету, иначе уже б давно закрыли.
ну относительно window.name на данній момент уязвимости нет. если найдете — напишите статью, интересно будет почитать, я вам подкину пару вопросов, да и покритикую с удовольствием :)
Очень сильно извиняюсь, но я реализовывал динамический script по долгу службы еще прошлой осенью… в сентябре. Да и раньше это было и работало… и механизм с iFrame тогда существовал и работал…
м? чего в этом нового? обертка в класс? хаафо, только были уже jQuery плагины для этого.
автору спасибо, помогла схема.
Заметил одну такую особенность…
если в срипте убрать вот эту строчку
finish[id] = callback;
то сервер на который отправляется запрос начинает изрядно подвисать.
всмысле тот веб-сервер, где находится требуемая url
2 раза запускал скрипт, и два раза на тот сайт становилось тяжело пробиться, возможно хостинг как то не адекватно реагировал… ну или в этот момент срабатывал чей-нибудь злой ддос ^)
JavaScript Cross Site (XSS) POST