Архитектура веб-приложения: обход same origin policy в ajax

@kojemiaka · Регистрация: 01.06.2012

Студворк — интернет-сервис помощи студентам

Добрый день,

Я разрабатываю веб-приложение, которое должно динамически подгружать данные. В целом схема такая, как на прикрепленном файле. Приложение (код на Javasript) будет размещено на сервере клиента.

Приложение будет размещено на сервере клиента и для работы должно получать данные с другого сервера, т.е. получается проблема same orinin policy, т.е. я не могу использовать обычный XMLhttpRequest.

Как я могу обойти эту проблему и всё же подключаться ко второму серверу для получения данных?

PS
Я уже знаю про cross domain ajax. Есть ли другие варианты?

@kalabuni · 15.06.2012, 14:48

Вот интересно, а книгу на японском языке вы написать не планируете?

Что, нет, не планируете?
А почему?
Японского языка не знаете?

Так как же вы собираетесь "разрабатывать" веб-приложение на Javascript'e, если не знаете Javascript?

Полагаете, что язык Javascript много проще, чем японский?
Считаете, что всякий дурак, не зная даже основ языка Javascript, может написать на нём веб-приложение?

Ну-ну... успехов

@kojemiaka · 15.06.2012, 14:49 **[ТС]**

Вам стало легче от того, что вы вылили на меня эту кучу го.на?

@kalabuni · 15.06.2012, 14:51

kojemiaka, мне?
Легче?

А причём тут я?
Я, не зная японского, книги писать на нём не собираюсь...
В отличие от вас.

@kojemiaka · 15.06.2012, 14:53 **[ТС]**

Вы при том, что вам не жалко своего времени для сообщения, которое не несёт для человека, задавшего вопрос, ни смысла не помощи. При этом сообщение не лестного содержания для меня.

Все вам хорошего. Если не можете ответить по теме, не засоряйте дискуссию.

@kalabuni · 15.06.2012, 15:01

kojemiaka, а темы, как таковой, нет.

Вы уже в курсе, что... "свой локоть укусить нельзя" (same orinin policy).
И в курсе, что есть способ укусить, используя соседскую собачку (cross domain ajax)

Но всё-равно спрашиваете - а как же мне всё-таки самому укусить?
Если это вы называете "темой", то ещё раз - "успехов вам!"

"Безумству храбрых поём мы песню"(с)

@ostgals · 15.06.2012, 16:04

Сообщение от kojemiaka

Как я могу обойти эту проблему и всё же подключаться ко второму серверу для получения данных?

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

Вкратце происходит так:
1) браузер через js шлет ajax-запрос на сервер
2) сервер шлет заголовки ответа
3) если заголовок Access-Control-Allow-Origin содержит ваш хост, то принимает ответ
4) если заголовка нет, или ваш хост не указан, то ответ игнорируется - браузер кидает исключение

До недавнего времени существовала проблема с браузером Опера, который даже при наличии верного хоста в заголовке не принимал ответ на кросс-доменный запрос. Однако в 12-ой версии все работает как надо.

Добавлено через 15 минут
Если нужно действительно кроссбраузерное решение, тогда применяется т.н. JSONP

@kojemiaka · 15.06.2012, 16:09 **[ТС]**

Сообщение от ostgals

если заголовок Access-Control-Allow-Origin содержит ваш хост, то принимает ответ

А мой хост - это хост, откуда должны браться данные? Как сделать, чтобы в заголовке Access-Control-Allow-Origin содержался правильный хост?

ЗЫ
Покопавшись, я понял, что передачу можно реализовать еще двумя способами.
1. Делать обычный ajax запрос, указываю url в той же доменной зоне. При этом задать DNS клиентского сервера делать перенаправление на удалённый сервер. В некотором роде создать алиас.

2. Создать серверное приложение на стороне клиента (jsp, php), которое будет обращаться к удалённому серверу и формировать результат в нужном виде для конечного пользователя.

Эти два варианта тоже сработают для описанной задачи?

@ostgals · 15.06.2012, 18:35

Сообщение от kojemiaka

Эти два варианта тоже сработают для описанной задачи?

Первый вариант очень часто применяется и называется проксирующим скриптом. То есть js отправляет ajax-запрос "своим" php-скриптам, а они в свою очередь запрашивают данные с другого сервера. Для php-скриптов, как правило, никаких ограничений на кросс-доменные запросы нет.

Второй вариант я не понял: "серверное приложение на стороне клиента" - это звучит как минимум странно.

Сообщение от kojemiaka

А мой хост - это хост, откуда должны браться данные?

В данном случае имелся в виду ваш сайт, который пытается получить данные с другого сервера.

@kojemiaka · 18.06.2012, 00:18 **[ТС]**

Серверное приложение на стороне клиента - это другой сервер. Дело в том, что клиентом я называю промежуточный сервер, на стороне которого будет размещён мой код. Вот, для наглядности я сделал схему. Всего есть 3 участника обмена информацией:

- конечный пользователь,
- веб-сервер (сайт), на который конечный пользователь заходит и
- сервер, откуда берутся некоторые данные

В схеме, что я нарисовал, средний сервер с помощью кода jsp обращается к серверу HDP, чтобы забрать данные и формирует ответ для конечного пользователя.

Такая схема может работать?

@ostgals · 19.06.2012, 21:08

Сообщение от kojemiaka

Такая схема может работать?

Конечно может.

@kojemiaka · 19.07.2012, 14:05 **[ТС]**

Добрый день,

Мне опять пришлось вернуться к проблеме same origin policy. Я подробней прочитал про решение с Access-Control-Allow-Origin, которое представляется очень интересным и простым. Как вы сказали, оно действительно поддерживается на данный момент во всех браузерах, кроме ИЕ9, но в 10 версии уже тоже всё работает.

Вопрос в другом, во внутреннем устройстве процедуры.
Как я понимаю такоё решение не спасает в принципе от sql-инъекции ни от ddos? Т.к. при несовпадении адреса клиента и того, что мы передаем в ответе в заголовке Access-Control-Allow-Origin запрос сервером в принципе обрабатывается и ответ с нужными данными отсылается, просто он не будет отображён браузером? Все так?

Новые блоги и статьи Все статьи Все блоги /
Уведомление о неверно выбранном значении справочника Maks 06.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "НарядПутевка", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если в документе выбран неверный склад. . .	Установка Qt Creator для C и C++: ставим среду, CMake и MinGW без фреймворка Qt 8Observer8 05.04.2026 Среду разработки Qt Creator можно установить без фреймворка Qt. Есть отдельный репозиторий для этой среды: https:/ / github. com/ qt-creator/ qt-creator, где можно скачать установщик, на вкладке Releases:. . .	AkelPad-скрипты, структуры, и немного лирики.. testuser2 05.04.2026 Такая программа, как AkelPad существует уже давно, и также давно существуют скрипты под нее. Тем не менее, прога живет, периодически что-то не спеша дополняется, улучшается. Что меня в первую очередь. . .	Отображение реквизитов в документе по условию и контроль их заполнения Maks 04.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеСпецтехники", разработанного в конфигурации КА2. Данный документ берёт данные из другого нетипового документа. . .
Фото всей Земли с борта корабля Orion миссии Artemis II kumehtar 04.04.2026 Это первое подобное фото сделанное человеком за 50 лет. Снимок называют новым вариантом легендарной фотографии «The Blue Marble» 1972 года, сделанной с борта корабля «Аполлон-17». Новое фото. . .	Вывод диалогового окна перед закрытием, если документ не проведён Maks 04.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать программный контроль на предмет проведения документа. . .	Программный контроль заполнения реквизитов табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: 1. Реализовать контроль заполнения реквизита. . .	wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/

@kojemiaka 0 / 0 / 0 Регистрация: 01.06.2012 Сообщений: 40

	Архитектура веб-приложения: обход same origin policy в ajax 15.06.2012, 14:28. Показов 4896. Ответов 11 Метки нет (Все метки) Добрый день, Я разрабатываю веб-приложение, которое должно динамически подгружать данные. В целом схема такая, как на прикрепленном файле. Приложение (код на Javasript) будет размещено на сервере клиента. Приложение будет размещено на сервере клиента и для работы должно получать данные с другого сервера, т.е. получается проблема same orinin policy, т.е. я не могу использовать обычный XMLhttpRequest. Как я могу обойти эту проблему и всё же подключаться ко второму серверу для получения данных? PS Я уже знаю про cross domain ajax. Есть ли другие варианты? Миниатюры 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	15.06.2012, 14:48
	Вот интересно, а книгу на японском языке вы написать не планируете? Что, нет, не планируете? А почему? Японского языка не знаете? Так как же вы собираетесь "разрабатывать" веб-приложение на Javascript'e, если не знаете Javascript? Полагаете, что язык Javascript много проще, чем японский? Считаете, что всякий дурак, не зная даже основ языка Javascript, может написать на нём веб-приложение? Ну-ну... успехов 0

@kojemiaka 0 / 0 / 0 Регистрация: 01.06.2012 Сообщений: 40
	15.06.2012, 14:49 [ТС]
	Вам стало легче от того, что вы вылили на меня эту кучу го.на? 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	15.06.2012, 14:51
	kojemiaka, мне? Легче? А причём тут я? Я, не зная японского, книги писать на нём не собираюсь... В отличие от вас. 0

@kojemiaka 0 / 0 / 0 Регистрация: 01.06.2012 Сообщений: 40
	15.06.2012, 14:53 [ТС]
	Вы при том, что вам не жалко своего времени для сообщения, которое не несёт для человека, задавшего вопрос, ни смысла не помощи. При этом сообщение не лестного содержания для меня. Все вам хорошего. Если не можете ответить по теме, не засоряйте дискуссию. 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	15.06.2012, 15:01
	kojemiaka, а темы, как таковой, нет. Вы уже в курсе, что... "свой локоть укусить нельзя" (same orinin policy). И в курсе, что есть способ укусить, используя соседскую собачку (cross domain ajax) Но всё-равно спрашиваете - а как же мне всё-таки самому укусить? Если это вы называете "темой", то ещё раз - "успехов вам!" "Безумству храбрых поём мы песню"(с) 0

@kojemiaka 0 / 0 / 0 Регистрация: 01.06.2012 Сообщений: 40
	18.06.2012, 00:18 [ТС]
	Серверное приложение на стороне клиента - это другой сервер. Дело в том, что клиентом я называю промежуточный сервер, на стороне которого будет размещён мой код. Вот, для наглядности я сделал схему. Всего есть 3 участника обмена информацией: - конечный пользователь, - веб-сервер (сайт), на который конечный пользователь заходит и - сервер, откуда берутся некоторые данные В схеме, что я нарисовал, средний сервер с помощью кода jsp обращается к серверу HDP, чтобы забрать данные и формирует ответ для конечного пользователя. Такая схема может работать? Миниатюры 0

@kojemiaka 0 / 0 / 0 Регистрация: 01.06.2012 Сообщений: 40
	19.07.2012, 14:05 [ТС]
	Добрый день, Мне опять пришлось вернуться к проблеме same origin policy. Я подробней прочитал про решение с Access-Control-Allow-Origin, которое представляется очень интересным и простым. Как вы сказали, оно действительно поддерживается на данный момент во всех браузерах, кроме ИЕ9, но в 10 версии уже тоже всё работает. Вопрос в другом, во внутреннем устройстве процедуры. Как я понимаю такоё решение не спасает в принципе от sql-инъекции ни от ddos? Т.к. при несовпадении адреса клиента и того, что мы передаем в ответе в заголовке Access-Control-Allow-Origin запрос сервером в принципе обрабатывается и ответ с нужными данными отсылается, просто он не будет отображён браузером? Все так? 0