Комментарии 33
НЛО прилетело и опубликовало эту надпись здесь
Еще неплохо обертывать ответ в try/catch или if(typeof callback == 'function'){...}
зачем? о0
Если что-то перезаписало обработчик или он, например, по таймауту был удален.
Последний вариант конечно правильнее, первый просто предотвратит ошибку если обработчика нет, тогда
как второй ничего не испортит, если переменной с именем обработчика была присвоена не функция, а значение какого-либо другого типа.
Последний вариант конечно правильнее, первый просто предотвратит ошибку если обработчика нет, тогда
как второй ничего не испортит, если переменной с именем обработчика была присвоена не функция, а значение какого-либо другого типа.
мдя, зачем глотать ошибку? о0
Ну почему же глотать, можно ее обрабатывать через catch.
А вообще это удобно, когда например, сервер «пингуется» в цикле, а ответы обрабатываются через динамически создаваемые — уникальные для каждого запроса — коллбэки (а не 1 глобальный). Тогда при возникновении проблем с коннектом, от сервера могу приходить ответы на те запросы, коллбэки которых были уже удалены по таймауту (функции с таким именем больше нет) и тогда выполнение такого ответа без обертки будет приводить к возникновению ошибок.
А вообще это удобно, когда например, сервер «пингуется» в цикле, а ответы обрабатываются через динамически создаваемые — уникальные для каждого запроса — коллбэки (а не 1 глобальный). Тогда при возникновении проблем с коннектом, от сервера могу приходить ответы на те запросы, коллбэки которых были уже удалены по таймауту (функции с таким именем больше нет) и тогда выполнение такого ответа без обертки будет приводить к возникновению ошибок.
Если подкинуть такую шпаргалку начинающему web-разработчику, то экзамен он явно не сдаст. Вы бы пример реализации привели…
JSONP
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Этот метод часто используется не для взлома, а для доступа к API сторонних сервисов. Как автор, обладатель доступа и т.п. страницы вы всегда можете создать нужный «таг».
любой клиент, получивший страничку от сервера может дальше делать с ней всё что угодно. Добавить ноду script динамически ничего не стоит. php, уязвимости и т.п. тут совершенно не в кассу =)
Переноси пост ^_~
Во первых — это очень полезное ограничение. Так как не позволяет злоумышленнику вызывать послать запрос со своего домена.
Во вторых — данным хаком вы снимаете это ограничение, так как имя колбэкфункции легко подсмотреть.
На мой взгляд статья из серии «Вредные советы».
В своих проектах для кросс доменных запросов я разрабатываю полноценный апи. Это звучит устрошающе, но на практике — на пару строк кода больше.
Но зато:
1. У вашего сайта автоматом появляется отлаженный апи и вы можете предоставлять к нему доступ сторонним разработчикам
2. На сайте не появляется громадных дыр в безопасности.
Во вторых — данным хаком вы снимаете это ограничение, так как имя колбэкфункции легко подсмотреть.
На мой взгляд статья из серии «Вредные советы».
В своих проектах для кросс доменных запросов я разрабатываю полноценный апи. Это звучит устрошающе, но на практике — на пару строк кода больше.
Но зато:
1. У вашего сайта автоматом появляется отлаженный апи и вы можете предоставлять к нему доступ сторонним разработчикам
2. На сайте не появляется громадных дыр в безопасности.
Вот пример api: www.wharrgarbl.ru/api/radio/demo/shpongle
Это обычный uri, в котором demo — ключ приложения, которому предоставлен доступ.
Uri возвращает json, который — во первых — кэшируется, во вторых — контролируется низкоуровневыми средствами nginx на количество запросов (не более одного запроса в 2 секунды), в третьих — универсален.
С другого своего www сайта я забираю результаты обычным curl'ом, а партнерское приложение — написано на air и забирает данные средствами flash
И овцы целы и волки сыты. ммм?
Это обычный uri, в котором demo — ключ приложения, которому предоставлен доступ.
Uri возвращает json, который — во первых — кэшируется, во вторых — контролируется низкоуровневыми средствами nginx на количество запросов (не более одного запроса в 2 секунды), в третьих — универсален.
С другого своего www сайта я забираю результаты обычным curl'ом, а партнерское приложение — написано на air и забирает данные средствами flash
И овцы целы и волки сыты. ммм?
вообщето этот хак не я придумал, и через него в современном интернете много что работает. и он присутствует во всех JS фреймворках, JSONP зовется.
а ограничение на самом деле в браузерах существует чтобы кукисы не передавались.
а ограничение на самом деле в браузерах существует чтобы кукисы не передавались.
Но Вы же его опубликовали?
www.habrahabr.ru/blogs/infosecurity/63176/
Обратите внимание на этот коммент:
* AztEK: «А если используется JSONP, то всё ещё проще, переопределяем callback-функцию и voilà»
www.habrahabr.ru/blogs/infosecurity/63176/
Обратите внимание на этот коммент:
* AztEK: «А если используется JSONP, то всё ещё проще, переопределяем callback-функцию и voilà»
метод этот уже классика. Тут плюс в том, что можно делать кроссдоменные запросы.
Минусы тоже есть. Нельзя читать приходящие заголовки, и например в FF и Opera не получиться отвемить запрос, он в любом случае будет дожидаться получения. Собственно из-за этого нельзя сделать полноценный abort запроса по таймауту. так же в FF замечено что если один тег будет гризиться очень долго, то он блочит остальные, которые накапливаются стеком, причем они загружаются, но не выполняются пока не загрузиться тот который тормозит.
Минусы тоже есть. Нельзя читать приходящие заголовки, и например в FF и Opera не получиться отвемить запрос, он в любом случае будет дожидаться получения. Собственно из-за этого нельзя сделать полноценный abort запроса по таймауту. так же в FF замечено что если один тег будет гризиться очень долго, то он блочит остальные, которые накапливаются стеком, причем они загружаются, но не выполняются пока не загрузиться тот который тормозит.
1. abort можно реализовать самому легко… создаём тег и ждём… если через N милисекунд он не выполнился то удаляем тег… и он не выполнится… а вот остановится или нет — незнаю :)
2. насколько мне известно, допускается 2 одновременных запроса на один и тотже домен. Но тут есть ещё ограничение на порядок выполнения… выполняются теги script в некоторых браузерах по разному… в некоторых FIFO а в некоторых беспорядочно :)
2. насколько мне известно, допускается 2 одновременных запроса на один и тотже домен. Но тут есть ещё ограничение на порядок выполнения… выполняются теги script в некоторых браузерах по разному… в некоторых FIFO а в некоторых беспорядочно :)
Недавно столкнулся с такой необходимостью — написал прокси скрипт на РНР. Отовсюду где он есть — милости просим, запрашивайте. А без него — ни-ни :). В ближайших планах Java и Perl.
Google для саджеста так давно делает, отличный пример. И, действительно, была статья на хабре про это…
Это бесполезное ограничение: для злоумышленников не представляет особой проблемы, а для разработчиков создает некоторое неудобство.Это невероятно важное ограничение: XMLHttpRequest позволяет делать POST и другие виды запросов, а ваш хак — нет.
Если бы этого ограничения не было, то на любом сайте можно было бы разместить JS-код, который бы от имени пользователя на любых других сайтах мог бы выполнять произвольные действия.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Шпаргалка => Cross Domain AJAX. Dynamic script Tag Hack