Комментарии 73
Хм, может я что-то не понимаю, но в JQuery есть crossDomain для $.ajax() api.jquery.com/jQuery.ajax/
О, круто, в 1.5 добавили. Не знал, спасибо.
Это для JSONP — посмотрите исходник, обычный AJAX запрос кроссдоменным от этого не станет
JSONP имеет ряд недостатков:
1) данные передаются через GET следовательно не айс с безопасностью, а я использовал запросы с http на https и смысл тогда в https если все сливаю в открытом виде, логин пароль явно не передаш.
2) ограничение на размер данных
1) данные передаются через GET следовательно не айс с безопасностью, а я использовал запросы с http на https и смысл тогда в https если все сливаю в открытом виде, логин пароль явно не передаш.
2) ограничение на размер данных
а что мешает использовать GET через HTTPS?
Если мы шлем с http на https то сам понимаешь. Скажем форма логина всплывает в попапе и соответственно тут проблема.
+ надо все это дело обрабатывать на сервере, в нашем же случае дополнительной обработки не надо и обычный ajax будет обработан также как и кросс доменный.
Но вам конечно в каком-то конкретном случае никто это сделать не мешает.
+ надо все это дело обрабатывать на сервере, в нашем же случае дополнительной обработки не надо и обычный ajax будет обработан также как и кросс доменный.
Но вам конечно в каком-то конкретном случае никто это сделать не мешает.
Признаюсь, я ничего не понял. «шлем с http на https, форма логина всплывает...» Пожалуйста, объясните что вы делаете по пунктам.
На самом деле можно просто использовать https для всей страницы, если требуется передача конфиденциальной информации, иначе на странице могут быть подключены незащищенные источники, которые имеют риск оказаться подмененными.
А вообще, ограничения придумали и продолжают поддерживать не просто так, почему бы не следовать нотации?
Разумеется, организация вебсервиса-прокси для межпротокольного/междоменного транспорта данных может добавить оверхед на сервер, зато будет больше защищенности и гибкости из-за серверной валидации/фильтрации/кеширования/…
А вообще, ограничения придумали и продолжают поддерживать не просто так, почему бы не следовать нотации?
Разумеется, организация вебсервиса-прокси для межпротокольного/междоменного транспорта данных может добавить оверхед на сервер, зато будет больше защищенности и гибкости из-за серверной валидации/фильтрации/кеширования/…
если у нас форма логина в попапе и присутствует на всех страницах https для всего сайта отпадает ибо весь сайт в нем передавать накладно и неправильно по своей сути.
Вам и тут доступны ограничения с помощью CORS, причем поддерживаются и серверные заголовки
Вам и тут доступны ограничения с помощью CORS, причем поддерживаются и серверные заголовки
Весь сайт — неправильно, поэтому страницу логона нужно делать минималистичной.
CORS решит проблему доступности междоменных запросов, но проблема подмены незащищенного содержимого все равно будет. Конечно, если все зависит от ТЗ, если вы пишете форум, вам возможно можно будет немного пожертвовать безопасностью во благо удобства, в отличие от проекта интернет-банка или любого портала, связанного с деньгами пользователей.
CORS решит проблему доступности междоменных запросов, но проблема подмены незащищенного содержимого все равно будет. Конечно, если все зависит от ТЗ, если вы пишете форум, вам возможно можно будет немного пожертвовать безопасностью во благо удобства, в отличие от проекта интернет-банка или любого портала, связанного с деньгами пользователей.
1) логин и пароль в JSONP запросе… — мне все казалось, что вместо пароля (если уж так нужно для JSONP) принято передавать ид сессии в куках, а сессию можно поднять и без JSONP. GET over HTTPS не работает, чтоли? :)
2) размер отправляемых данных ограничен (8KB), а принимаемых безграничен, но JSONP применяют, чтобы данные получать, а не отправлять данные. Отправить можно хоть терабайт на любой домен постом, например через форму.
Основной недостаток JSON — сложно контролировать сетевые ошибки.
2) размер отправляемых данных ограничен (8KB), а принимаемых безграничен, но JSONP применяют, чтобы данные получать, а не отправлять данные. Отправить можно хоть терабайт на любой домен постом, например через форму.
Основной недостаток JSON — сложно контролировать сетевые ошибки.
это не JSON — а JSONP и то только через скрипт или фрейм
простите, у меня форма логина на ajax и данный шлются с http на https, какой id я передам если ещё не залогинился + а как сессию поднять? я не хочу в get слать запрос с паролем а открытом виде.
И опять же для JSONP нужна специальная обработка на сервере отличная от обычного ajax. Опять же проблемы.
| но JSONP применяют
у меня и задача так не стоит «принимать данные» есть отправка файлов, а либа кстати позволяет это делать!
И опять же для JSONP нужна специальная обработка на сервере отличная от обычного ajax. Опять же проблемы.
| но JSONP применяют
у меня и задача так не стоит «принимать данные» есть отправка файлов, а либа кстати позволяет это делать!
Сразу скажу, что я вам не предлагал использовать JSONP, просто уточняю некоторые моменты, которые мне показались странными в вашем коменте. Да и для логина JSONP ну никак не приемлем.
Для логина обычно делают отдельную страницу, которая открывается по HTTP(S) и пересылает данные тоже по HTTP(S), а уж потом если так нужно редиректятся на HTTP — отработанная схема. Либо создают форму (POST, HTTPS) на основной странице и постят в скрытый фрэйм (страница не перезагружается, успешность авторизации можно смотреть по кукам).
Не хочу придираться и не защищаю JSONP, но обернуть данные в малюсенькую обертку я уж никак не могу назвать «специальной обработкой».
Для логина обычно делают отдельную страницу, которая открывается по HTTP(S) и пересылает данные тоже по HTTP(S), а уж потом если так нужно редиректятся на HTTP — отработанная схема. Либо создают форму (POST, HTTPS) на основной странице и постят в скрытый фрэйм (страница не перезагружается, успешность авторизации можно смотреть по кукам).
Не хочу придираться и не защищаю JSONP, но обернуть данные в малюсенькую обертку я уж никак не могу назвать «специальной обработкой».
то есть если я со страницей работаю на ajax и jsonp мне придется всегда писать 2 реализации ответа и учитывать возможность jsonp, тут можно без этого обойтись
+ если как я писал выше надо отправлять много форм плагин jquery form требует большей
доработки
+ как нам понять, что произошла ошибка при ответе, скажем пол логике юзер увидит бесконечный прелоадер если мы решим как-то отметить факт отсылки запроса
Я старался предложить наиболее удобное и гибкое решение
+ если как я писал выше надо отправлять много форм плагин jquery form требует большей
доработки
+ как нам понять, что произошла ошибка при ответе, скажем пол логике юзер увидит бесконечный прелоадер если мы решим как-то отметить факт отсылки запроса
Я старался предложить наиболее удобное и гибкое решение
Господа зачем так тролить, если в какой-то вашей ситуации позволительно использовать jsonp то без проблем.
Моя задача была предложить гибкое и удобное решение для кросс доменных запросов и думаю те кому это интересно и нужно возьмут на заметку.
Также более-менее объёмный функционал врятли будете браться реализовать на jsonp. Также библиотека предоставляет довольно обширный функционал.
+ отлавливать ошибки на jsonp на порядок сложнее, особенно если послать одновременно несколько запросов. И пользователь может довольно долго ожидать ответа от сервера если мы не предусмотрим таймаут для сброса ожидания запроса (например preloader убрать)
так что тут ни к чему холиварить, каждая задача должна получить своё решение, универсально и идеального для всех случаем нет
Моя задача была предложить гибкое и удобное решение для кросс доменных запросов и думаю те кому это интересно и нужно возьмут на заметку.
Также более-менее объёмный функционал врятли будете браться реализовать на jsonp. Также библиотека предоставляет довольно обширный функционал.
+ отлавливать ошибки на jsonp на порядок сложнее, особенно если послать одновременно несколько запросов. И пользователь может довольно долго ожидать ответа от сервера если мы не предусмотрим таймаут для сброса ожидания запроса (например preloader убрать)
так что тут ни к чему холиварить, каждая задача должна получить своё решение, универсально и идеального для всех случаем нет
Последний раз, когда его использовали, у него с IE были проблемы.
Скажите, почему у вас тема называется «Cross-domain ajax», а описание идёт 8 техник, 7 из которых не имеют к этой аббревиатуре отношения?
Под ajax обычно большинство понимает запрос данных на js без перезагрузки страницы, не связывая слово ajax c XMLHTTPRequest, а те кто изначально пользуются jquery могу и не знать о существовании оного.
Не буду отрицать, допустил некорректное выражение, собственно первый пост на хабре. Аббревиатуру ajax взял в ковычки.
Не буду отрицать, допустил некорректное выражение, собственно первый пост на хабре. Аббревиатуру ajax взял в ковычки.
Вы не могли бы дать ссылку на определение Аббревиатуры «Ajax», в которой говориться что «Ajax» это только XHR (Как я понимаю вы только этот способ назвали айяксом).
В самой аббревиатуре про объект XHR нет ни слова, английская википедия называет айяксом группу асинхронных методов обмена с сервером, из которых самым частым транспортом выступает XHR, при этом про эксклюзивность этого объекта на аббревиатуру ничего не говориться. Кстати определение JSONP, находиться в категории айякса.
Русская же википедия называет три «технологии динамического обращения к серверу „на лету“», называя их одним из принципов аяйкса.
Jesse James Garrett впервые использовав эту аббревиатуру называл ею целую группу технологий. Тип данных, например, исходя из той статьи, всегда должен был быть XML, а XML всегда должен обрабатываться через XSLT
Цитата Nicholas C. Zakas
В самой аббревиатуре про объект XHR нет ни слова, английская википедия называет айяксом группу асинхронных методов обмена с сервером, из которых самым частым транспортом выступает XHR, при этом про эксклюзивность этого объекта на аббревиатуру ничего не говориться. Кстати определение JSONP, находиться в категории айякса.
Русская же википедия называет три «технологии динамического обращения к серверу „на лету“», называя их одним из принципов аяйкса.
Jesse James Garrett впервые использовав эту аббревиатуру называл ею целую группу технологий. Тип данных, например, исходя из той статьи, всегда должен был быть XML, а XML всегда должен обрабатываться через XSLT
Цитата Nicholas C. Zakas
By now, nearly everyone who works in web development has heard of the term Ajax, which is simply a term to describe client-server communication achieved without reloading the current page. Most articles on Ajax have focused on using XMLHttp as the means to achieving such communication, but Ajax techniques aren't limited to just XMLHttp. There are several other methods.
Здесь описаны два способа междоменного доступа
developer.mozilla.org/en/DOM/window.postMessage c 3+ уже есть. сама суть таких месаджей кросс доменный запрос
ну crazy frame не о name говориться а о hash. К windiw.name есть всегда доступ
Готовая библиотека — эт хорошо. Благодрности.
Вообще для крос домена обычно использую XMLHTTPRequest 2 / XDomainRequest — когда Firefox 3.5, Safari 4/Chrome 3 и IE8 и Flash, прокси и т.п. кога нужны все остальные)
Вообще почитайте — Обмен данными для документов с разных доменов
Это:
Полностью cross-domain
Прокси
Script
Flash
XhrIframeProxy
Кросс-доменный скриптинг с общим наддоменом
XMLHTTPRequest
HTML5, XDomainRequest
И продолжение: Обмен данными между доменами. Часть 2.
HTML5: postMessage
XMLHTTPRequest 2 / XDomainRequest
+ подборка статей
Вообще для крос домена обычно использую XMLHTTPRequest 2 / XDomainRequest — когда Firefox 3.5, Safari 4/Chrome 3 и IE8 и Flash, прокси и т.п. кога нужны все остальные)
Вообще почитайте — Обмен данными для документов с разных доменов
Это:
Полностью cross-domain
Прокси
Script
Flash
XhrIframeProxy
Кросс-доменный скриптинг с общим наддоменом
XMLHTTPRequest
HTML5, XDomainRequest
И продолжение: Обмен данными между доменами. Часть 2.
HTML5: postMessage
XMLHTTPRequest 2 / XDomainRequest
+ подборка статей
Я читал эти статьи, развернутых примеров тут нету, я тоже даю краткое описание способов, в этих статьях оно чуть более развернуто. И когда стоит задача «сделать» человеку они не помогут (( ибо ничего реально там не предлагают.
ie7 к сожалению тоже никуда не деть, если 6 можно опустить то 7 рановато. ну и старая опера имеет немного другие стандартны постмесаджа
ie7 к сожалению тоже никуда не деть, если 6 можно опустить то 7 рановато. ну и старая опера имеет немного другие стандартны постмесаджа
>Использовав тэг мы можем обратиться к другим доменам, однако результат придет в виде json ответа который мы не сможем обработать, jsonp предлагает следующее решение: передавая серверу имя функции, мы получаем в ответе не голые данные, а parseResponse({«paper»: «A4», «count»: 5}), что вызовет функцию parseResponse.
А если не использовать тэг, а просто вызывать .ajax(...) с нужными параметрами?
Буквально пару дней назад немного ковырялся с jQuery, играл с кросс-доменным AJAX и без проблем получил обычный JSON в ответ на JSONP-запрос.
Буду дома — кину пример. Ну или пусть TheShock кинет, если раньше меня прочитает это — он мне как раз помогал разобраться с этим делом.
А если не использовать тэг, а просто вызывать .ajax(...) с нужными параметрами?
Буквально пару дней назад немного ковырялся с jQuery, играл с кросс-доменным AJAX и без проблем получил обычный JSON в ответ на JSONP-запрос.
Буду дома — кину пример. Ну или пусть TheShock кинет, если раньше меня прочитает это — он мне как раз помогал разобраться с этим делом.
Ну вообще описывая методы я не ориентировался на jq или другие библиотеки, а хотел описать сами методы.
Во вторых я описал почему не могу взять jsonp в качестве решения. так что тут скорее надо смотреть по ситуации
Во вторых я описал почему не могу взять jsonp в качестве решения. так что тут скорее надо смотреть по ситуации
Обещанный пример: pastebin.com/ApBSSwhN
AJAX-запрос, запрашивающий цитату из Forismatic и получающий чистый JSON в ответ.
AJAX-запрос, запрашивающий цитату из Forismatic и получающий чистый JSON в ответ.
Пригодиться, сенкс
«Простое» решение по-вашему — тяжелая библиотека с кучей костылей? Есть же JSONP, он позволяет почти что угодно сделать, что вам еще нужно? там только вроде ошибки запросов трудно отловить, а так все нормально. Если нужно больше контроля, ставим прокси-скрипт на свой сервер. Вот и все, и проблем меньше, и библиотеку с костылями тащить не надо.
Есть еще метод Кроссдоменный AJAX на основе CSS, хотя он работает не во всех браузерах.
А почему бы не использовать запрос к локальной пхпшке, которая через curl отправляет и получает всё, что требуется?
Если бы я заморачивался с темой кроссдомена, я бы от curl и начал плясать…
Если бы я заморачивался с темой кроссдомена, я бы от curl и начал плясать…
Этот вариант я использовал много раз и честно сказать не пойму, почему об этом в первую же очередь не вспоминают
я указал в списке подобный вариант.
+ если вам нужен запрос с http на https смысл в этом пропадает.
Да и надо опять же смотреть на ситуацию, что вам надо получить, какие требования предъявляют.
+ если вам нужен запрос с http на https смысл в этом пропадает.
Да и надо опять же смотреть на ситуацию, что вам надо получить, какие требования предъявляют.
Одно не понимаю: зачем нужны такие ограничения в браузере, если они все равно преодолеваются -> если вебсервер взломан, злоумышленники достигнут цели.
Ограничения нужны для того чтобы у вас скажем куки любо желающий не слил
Так ограничения все равно преодолеваются!
А вещи типа JSONP вообще больше на хак похожи, чем на нормальную разработку.
А вещи типа JSONP вообще больше на хак похожи, чем на нормальную разработку.
вы себе не представляете сколько хаков многие использует при фронтенд разработке сайтов, даже не задумываясь об этом. Ибо сейчас любой браузер не поддерживает стандарты, где-то что-то да не поддерживает, кто-то в большей степени кто-то в меньшей. И это суровая действительность. В отличии от серверной разработке, где можно выставлять требования к серверу и по на нем
А что если добавлять в head элемент script в рантайме? Вроде бы, оно разрешает указывать в src левые хосты?
Пусть меня и заминусуют, но у Вас серьёзные проблемы с тся/ться, мне было очень сложно читать.
Для тех кто столкнулся с проблеммой Cross-domain «ajax»
Вот простое решение server-side proxy на основе NGINX
После этого все запросы на http://yousite.com/api.server.com/do_something.ajax через NGINX уйдут на http://api.server.com/do_something.ajax
Вот простое решение server-side proxy на основе NGINX
location /api.server.com/
{
rewrite \/api.server.com(\/.*)$ $1 break;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass api.server.com;
proxy_set_header Host api.server.com;
proxy_connect_timeout 1;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404;
proxy_intercept_errors on;
expires 30;
add_header Content-Type text/javascript;
break;
}
После этого все запросы на http://yousite.com/api.server.com/do_something.ajax через NGINX уйдут на http://api.server.com/do_something.ajax
Хорошее решение если у вас есть возможность влезть в настройки сервера и вы используете NGINX. Конечно такие решения удобны.
А скажем для Apach+TomCat можно подобное сотворить?
А скажем для Apach+TomCat можно подобное сотворить?
>А скажем для Apach+TomCat можно подобное сотворить?
Думаю что можно httpd.apache.org/docs/2.2/mod/mod_proxy.html
Надо поэкспериментировать
Думаю что можно httpd.apache.org/docs/2.2/mod/mod_proxy.html
Надо поэкспериментировать
«Не хочу показаться слишком говнистым» (с), но было был классно улучшить форматирование статьи — абзацы, подсветка кода, списки и т.п. Поймите меня правильно, так воспринимать ваш труд будет гораздо удобнее!
Библиотека супер. Мне на днях буквально спасла задницу. Рекомендую, зависимости никакой. RPC между двумя приложениями сделал на раз два.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cross-domain «ajax» — простое решение