Как сделать кроссдоменный ajax
Кросс-доменные ajax-запросы и причем здесь php
Пробуем получить данные с другого домена
А теперь давайте получим эту html-ку ajax-ом прямо из консоли браузера.
Не будем париться с нативным javascript-ом, а дернем запрос с помощью jQuery.get() и выведем в консоль то, что получили в ответ с сервера.
Откройте прямо сейчас developer tools в браузере и на вкладке console выполните этот запрос.
Вы увидите примерно следующее 
Я, например, проверял запросы на футбольном сайте bombardir.ru. И заодно подивился, какой только дряни не вываливается в консоль даже на таких достаточно известных сайтах. Впрочем, разговор не про это.
Выполните запрос с другого домена и Вы увидите в консоли уже не такую благостную картину. 
Говорит, невозможно загрузить, данных нет и вообще печаль.
Если откроете вкладку Network и найдете там соотвествующий запрос, то увидите, сервер даже вернул нам 200 ОК 
А содержимого файла нет. В чем подвох?
Что пошло не так и каково будет решение
Подвох в том, что политика интернетов не разрешает браузерам вытаскивать данные с каких угодно ресурсов. Кроме тех случаев, когда эти ресурсы сами заинтересованы в раздаче конкретных данных.
Наш случай именно такой. Чтобы дать разрешение на использование html-файлика откуда угодно, нужно при запросе оного файла отправлять http-заголовок Access-Control-Allow-Origin: *
Теперь вопрос, как это сделать. Если у Вас (или же у админов) есть доступ к nginx, то одним способом будет настроить прокидывание этого заголовка средствами веб-сервера. Вы идете к админам с соответствующей просьбой или гуглите сами нужные конфиги для Вашего веб-сервера.
Если же этого доступа нет, как например, у практически любого хостинг-провайдера на недорогом тарифе, то нужно выкручиваться самостоятельно. И здесь на помощь приходит php. Идея в том, чтобы закинуть нашу html-ку в php-файл, который и прокинет заголовок, и отдаст нужное содержимое.
Получится так, создаем файл template.php и первой строкой запишем php-команду
То есть содержимое template.php будет таким, не забудьте про php-шные вопросы и скобки 
Файл на webdevkin-е создан и лежит здесь (откроется в новой вкладке). Давайте теперь попробуем запросить его с другого домена и посмотрим, что будет
Заглянем на вкладку Network.
Обратите внимание, в блоке Response Headers появился интересующий нас заголовок Access-Control-Allow-Origin: * 
В целом статья закончена. Осталось собрать мысли в кучу и добавить еще немного информации.
Обобщаем и подводим итоги
Вот что увидите в консоли, попытавшись выполнить тот же запрос с любого https-сайта. 
Поэтому если Вы собираетесь заниматься встраиваемыми виджетами или чем-то подобным, Вам обязательно нужно поставить ssl-сертификат на своем сайте.
WCF + Cross Domain Ajax Calls (CORS) + Авторизация
Добрый день!
Хотелось бы продемонстрировать один из возможных подходов к решению проблемы работы с WCF сервисами с различных доменов. Найденная мной информация по данной теме была или неполной, или содержала избыточное количество информации, затрудняющей понимание. Хочу рассказать о нескольких способах взаимодействия WCF и AJAX POST запросов, включающих в себя информацию о Cookies и авторизации.
Как известно, просто так AJAX вызов на другой домен не заработает, в силу соображений безопасности. Для решения данной проблемы был придуман и релизован стандарт CORS(wiki, mozilla). Этот стандарт подразумевает использование специфичных HTTP заголовков для разрешения и ограничения доступа. Упрощенный процесс коммуникации с использованием данного протокола подразумевает следующее:
Запрос:
GET /resources/public-data/ HTTP/1.1
Host: bar.other
Origin: foo.example
[Другие заголовки]
Ответ:
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Access-Control-Allow-Origin: *
Content-Type: application/xml
Заголовки
По данной теме существует определенное количество информации разнообразного качества. К сожалению, WCF не позволяет стандартными средствами использовать эти заголовки, однако существует несколько вариантов решения этой пробемы. Я предлагаю вашему вниманию некоторые из них.
Решение с использованием web.config.
Данное решение подразумевает добавление необходимых заголовков прямо в web.config.
Отличается своей простотой и негибкостью. В частности, конкретно данный пример невозможно использовать, если возможных доменов более одного, кроме того он разрешает CORS на весь сайт(в конкретном случае).
Решение с использованием Global.asax
Данное решение подразумевает написание в Global.asax.cs кода, добавляющего необходимые заголовки в каждый запрос.
Это решение поддерживает несколько доменов, но распространяется на весь сайт. Безусловно, все условия на конкретные сервисы можно прописать тут же, но на мой взгляд это сопряжено с неудобствами в поддержке списка разрешенных сервисов.
Решение с добавлением заголовков в коде WCF сервиса
Данное решение отличается от предыдущего лишь тем, что заголовки добавляются для конкретного сервиса или метода. В общем случа решение выглядит так:
Данный подход позволяет ограничить использование CORS в рамках сервиса или даже метода. Основной минус — вызов AddCorsHeaders необходим в каждом методе сервиса. Плюс — простота использования.
Решение с использованием собственных EndPointBehavior и DispatchMessageInspector
Данный подход использует возможности WCF по расширение функциональности.
Создаются 2 класса EnableCorsBehavior :
Добавляем в web.config созданный EnableCorsBehavior :
Находим и добавляем созданное для EnableCorsBehavior расширение в конфигурацию Behavior нашего Endpoint ‘a
Разумеется, существует и аналогичное WCF расширение для работы с preflight запросами, об одном из них можно будет прочитать по ссылке из списка литературы в конце статьи. Основной минус — необходимость добавления метода GetOptions в тело сервиса и немалое количество дополнительного кода. С другой стороны, данный подход позволяет практически полностью разделить логику сервиса и логику коммуникации.
Пара слов о Javascript и браузерах
К сожалению, функциональность связанная с отправкой авторизационных данных стала доступна для IE только с 10 версии, браузеры IE8/9 не поддерживают отправку данной информации, и способны работать только с GET и POST.
XMLHttpRequest: кросс-доменные запросы
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Более новая информация по этой теме находится на странице https://learn.javascript.ru/fetch-crossorigin.
Обычно запрос XMLHttpRequest может делать запрос только в рамках текущего сайта. При попытке использовать другой домен/порт/протокол – браузер выдаёт ошибку.
Существует современный стандарт XMLHttpRequest, он ещё в состоянии черновика, но предусматривает кросс-доменные запросы и многое другое.
Большинство возможностей этого стандарта уже поддерживаются всеми браузерами, но увы, не в IE9-.
Впрочем, частично кросс-доменные запросы поддерживаются, начиная с IE8, только вместо XMLHttpRequest нужно использовать объект XDomainRequest.
Кросс-доменные запросы
Разберём кросс-доменные запросы на примере кода:
Контроль безопасности
Кросс-доменные запросы проходят специальный контроль безопасности, цель которого – не дать злым хакерам™ завоевать интернет.
Серьёзно. Разработчики стандарта предусмотрели все заслоны, чтобы «злой хакер» не смог, воспользовавшись новым стандартом, сделать что-то принципиально отличное от того, что и так мог раньше и, таким образом, «сломать» какой-нибудь сервер, работающий по-старому стандарту и не ожидающий ничего принципиально нового.
Давайте, на минуточку, вообразим, что появился стандарт, который даёт, без ограничений, возможность делать любой странице HTTP-запросы куда угодно, какие угодно.
Как сможет этим воспользоваться злой хакер?
Он сделает свой сайт, например http://evilhacker.com и заманит туда посетителя (а может посетитель попадёт на «злонамеренную» страницу и по ошибке – не так важно).
Спецификация CORS налагает специальные ограничения на запросы, которые призваны не допустить подобного апокалипсиса.
Запросы в ней делятся на два вида.
Простыми считаются запросы, если они удовлетворяют следующим двум условиям:
«Непростыми» считаются все остальные, например, запрос с методом PUT или с заголовком Authorization не подходит под ограничения выше.
Принципиальная разница между ними заключается в том, что «простой» запрос можно сформировать и отправить на сервер и без XMLHttpRequest, например при помощи HTML-формы.
То есть, злой хакер на странице http://evilhacker.com и до появления CORS мог отправить произвольный GET-запрос куда угодно. Например, если создать и добавить в документ элемент
Комментарии
Небезопасный cross-origin resource sharing
Что такое CORS?
CORS — это механизм безопасности, который позволяет веб-странице из одного домена обращаться к ресурсу с другим доменом (кросс-доменным запросом). Без таких функций, как CORS, веб-сайты ограничиваются доступом к ресурсам одного и того же происхождения через так называемую политику единого происхождения.
Первым шагом в понимании CORS является знание того, как работают некоторые функции безопасности веб-браузеров. По умолчанию веб-браузеры не разрешают AJAX-запросы на сайты, кроме сайта, который вы посещаете. Это называется политикой единого происхождения, и это важная часть модели веб-безопасности. Совместное использование ресурсов между разными источниками (cross-origin resource sharing) — это механизм HTML 5, который дополняет политику единого происхождения для упрощения совместного использования ресурсов домена между различными веб-приложениями.
Спецификация CORS определяет набор заголовков, которые позволяют серверу и браузеру определять, какие запросы для междоменных ресурсов (изображения, таблицы стилей, сценарии, данные и т. д.) разрешены, а какие нет. CORS является техникой для ослабления правила одного источника, позволяя JavaScript на web странице обрабатывать REST API запросы от другого источника.
По своей сути, CORS это защитная оболочка для браузера. Совместное использование ресурсов между разными источниками очень важно в современном мире сложных веб-приложений, и все браузеры поддерживают его. В частности, CORS обычно используется для междоменных AJAX запросов.
Обмен запросами
Взаимодействие ресурсов начинается с отправки GET, POST или HEAD запросу к тому или иному ресурсу на сервере. Тип содержимого POST запроса ограничен application/x-www-form-urlencoded, multipart/form-data или plaintext. Запрос включает заголовок Origin, который и указывает на происхождение клиентского кода.
Веб приложение проверяет происхождение запроса и на основании Origin либо принимает запрос, либо отвергает его. Если запрос принят, запрашиваемые сервер ответит заголовком Access-Control-Allow-Origin. Этот заголовок будет указывать клиенту с каким происхождением будет разрешен доступ. Принимая во внимание, что Access-Control-Allow-Origin соответствует Origin запроса, браузер разрешит запрос.
При запросе на site.ru/resource с site.com/some будут следующие заголовки:
Если запрос принят, запрашиваемый сервер добавляет к ответу заголовок Access-Control-Allow-Origin, содержащий домен запроса site.com.
Access-Control-Allow-Origin указывает, какие домены могут обращаться к ресурсам сайта. Например, если компания имеет домены site.ru и site.com, то ее разработчики могут использовать этот заголовок, чтобы предоставить site.com доступ к ресурсам site.ru.
Access-Control-Allow-Methods определяет, какие HTTP-запросы (GET, PUT, DELETE и т. д.) могут быть использованы для доступа к ресурсам. Этот заголовок позволяет повысить безопасность, указав какие методы действительны, когда site.com обращается к ресурсам site.ru.
Access-Control-Max-Age указывает время жизни предзапроса (также он называется «предполетным») доступности того или иного метода, после которого должен быть выполнен новый запрос на тот или иной метод.
Отказ от политики запроса из белого списка
Использование правильных заголовков, методов и доверенных доменов вроде бы не позволяет злоумышленнику вклиниться в эту цепочку обмена. На самом деле это не так. И подводит здесь коварная *.
Наиболее распространенная проблема безопасности при внедрении CORS — это отказ от проверки запроса белых списков. Зачастую разработчики устанавливают значение для Access-Control-Allow-Origin в ‘*’. Это позволяет любому домену в Интернете получать доступ к ресурсам этого сайта.
Основания проблема кроется в том, что многие компании размещают API в пределах домена, не ограничивания к нему доступ политикой «белого списка». Это порождает уязвимость.
Attack scenario
Большинство веб-приложений использует файлы cookie для отслеживания информации о сеансе. При генерации cookie ограничены определенным доменом. При каждом HTTP запросе к этому домену браузер подставлять значение cookie, созданные для этого домена. Это относится к каждому HTTP запросу — для получения изображений, страниц или AJAX-вызовов.
Что это означает на практике: при авторизации в goodsite.ru, cookie генерируются и хранятся для этого домена. Веб-приложение goodsite.ru основано на технологии SPA и содержит REST API на goodsite.ru/api для взаимодействия с помощью AJAX. Предположим, что вы просматриваете badsite.ru, будучи авторизованным на goodsite.ru. Без ограничения Access-Control-Allow-Origin по белому списку (с указанием сайта) badsite.ru может выполнить любой разрешенный аутентифицированный запрос к goodsite.ru, даже не имея прямого доступа к сессионной cookie!
Это связано с тем, что браузер автоматически привязывает файлы cookie к goodsite.ru для любых HTTP запросов в этом домене, включая AJAX запросы от badsite.ru в goodsite.ru. Таким образом атакующий может взаимодействовать даже с вашим внутренним ресурсом, недоступным в сети интернет и находящимся в корпоративной сети.
Наглядные примеры
В качестве примера приведу код OWASP Testing Guide. Уязвимое веб-приложение, с неверно настроенной политикой Access-Control-Allow-Origin.
Например, такой запрос будет показывать содержимое файла profile.php:
Т.к. отсутствует проверка URL-адреса, атакующий может добавить скрипт, который будет выполняться в контексте домена example.foo со следующим URL:
В качестве еще одного примера рекомендую ознакомиться с Stealing contact form data on www.hackerone.com using Marketo Forms XSS with postMessage frame-jumping and jQuery-JSONP — публичным раскрытием уязвимости, включая небольшую видео-демонстрацию.
Защитные меры
Используйте белые списки доменов. Если такой возможности нет — размещайте API вне домена — политики CORS для sub.site.ru, site.ru и даже разным портам будут различаться.
Указывайте конкретные методы обращения.
Не используйте wildcard — CORS учитывает или * или домен.
Обязательно указывайте протокол. «Access-Control-Allow-Origin: site.ru» не будет учтён, поскольку протокол отсутствует.
При использовании Access-Control-Allow-Credentials: true всегда используется Access-Control-Allow-Origin: домен — при использовании * браузер не получит ответ.
AJAX запрос примеры, — на чистом Javascript, так же AJAX запрос jquery, Fetch запрос, всё это в разных вариантах, GET POST JSON
27.02.2019
Рассмотрим примеры AJAX запросов:
Каждый ответ от сервера включает в себя
Элементы кода, которые будут использованы в примерах.
url – это путь до файла на сервере, который будет обрабатывать наш запрос. В примерах с GET методом, в нем будут передаваться данные со стороны клиента.
.setRequestHeader() – это метод для указания передаваемых заголовков, здесь мы можем указать что данные идут в url либо закрытым способом, либо хотим получить данные от сервера в json формате.
.send() – это последний этап создания http запроса. С помощью него также можно передать тело запроса т.е. данные от браузера к серверу. Можно не чего не передавать или прямо указать null.
onreadystatechange – это событие которое случится когда нам придет ответ от сервера.
readyState – это метод экземпляра, который сообщает статус HTTP-запроса, вот возможные значения которые он может дать:
| Значение | Описание |
| 0 | Метод open() не вызван |
| 1 | Метод open() вызван |
| 2 | Получены заголовки ответа |
| 3 | |
| 4 | Передача ответа выполнена |
status или statusText – возвращают статус http заголовков, нам нужен ответ 200. Хотя бывают и 404 или 500.
.responseText – данные, которые придут от сервера в виде строки.
.response – данные вернуться в json формате, тут как бы мы преобразуем сразу в объект, и дальше работаем уже как с объектом.
.text() – используется в запросе fetch, возвращает строку.
.json() – используется в запросе fetch, возвращает json обращенный в объект.
1. GET AJAX запрос на чистом JavaScript
Делаем запрос на чистом JavaScript, например к файлу ajax_quest.php, который находится на сервере, и будет возвращать то что мы ему передали.
2. POST AJAX запрос на чистом JavaScript к PHP файлу на сервере
Принцип такой же как и у GET запроса, но не забываем что GET запросом данные отправляются открыто. У POST запроса данные скрыты, и в большинстве своем желательно использовать POST запросы.
3. JSON AJAX POST запрос к серверу, на чистом Javascript
Запрос на чистом Javascript. Получаем данные в JSON формате.
4. JQuery GET & POST AJAX запрос к PHP на сервере
Работаем с сервером через фреймворк JQuery.
5. Fetch GET на чистом Javascript
Fetch обертка над XHR
6. Запрос на чистом Javascript «Vanila» Fetch + POST метод
7. Fetch POST + JSON
Данный метод сейчас мало какой браузер поддерживает. Но есть костыли. Этот код работает, попробуйте разобраться что к чему. С удовольствием узнаю как лучше тут поступать.
8. Кросдоменный запрос JSONP Fetch + GET метод в github
Кросдоменный AJAX запрос в репозиторий github. Репозиторий возвращает json объект с именами.