Смешивание при помощи Ajax

Mashup - это Web-приложение, интегрирующее содержимое из нескольких источников и представляющее его на одной странице. Сервер выполняет запросы к каждому источнику содержимого, анализирует получаемую информацию и объединяет результаты на странице для передачи в браузер, как показано на рисунке 1.

Ajax-приложение (Asynchronous JavaScript + XML) позволяет Web-странице получать содержимое от сервера и обновлять себя асинхронно, используя JavaScript™-код, как показано на рисунке 2. Таким способом пользователи могут взаимодействовать с полнофункциональным пользовательским интерфейсом (user interface - UI) без перезагрузки всей страницы. Сервер передает начальную страницу в браузер, который запрашивает сервер для получения обновленного содержимого страницы. Асинхронный JavaScript-код часто использует XML для кодирования данных, однако распространены и другие форматы данных, такие как JavaScript Object Notation (JSON), HTML и текст с разделителями.

Ajax mashup - это гибридное Web-приложение. Оно использует Ajax-технологии для предоставления полнофункционального UI, обновляющего себя при помощи содержимого, извлекаемого асинхронно из нескольких источников. Сервер передает в браузер начальную страницу, которая затем формирует вызовы для извлечения обновленного содержимого. Эти вызовы могут быть сделаны напрямую сторонним источникам из браузера, либо поступать на сервер, который работает как прокси для стороннего содержимого.

В начало

Круглые гвозди, квадратные дырки

Когда разрабатывались элементы современных браузеров, Ajax mashup-приложений еще не было и в помине. В браузеры, HTTP-протокол (Hypertext Transfer Protocol), HTML или XHTML не было встроено ничего, специально предназначенного для адаптации браузеров к безопасному и надежному асинхронному извлечению содержимого из нескольких источников. Некоторые функциональные возможности в HTTP-спецификациях World Wide Web Consortium (W3C), которые можно было бы использовать для mashup (например, Document Object Model (DOM) Level 3 Load and Save Specification), в большинстве браузеров были реализованы не полностью либо не реализованы вообще.

Dynamic HTML (DHTML) изначально не использовался с динамически извлеченным содержимым. Элементы представления и элементы данных динамической Web-страницы, а также сценарии для работы с ними доставлялись все вместе. Сценарии могли отображать, скрывать, перемещать, создавать и уничтожать объекты документа для создания динамических эффектов, но каждый раз, когда нужны были новые данные от сервера, страница полностью заменялась новой. Поток данных был синхронизирован с перезагрузкой страницы.

Поэтому разработчики, хотевшие создавать гибридные Web-приложения, которые мы теперь называем словом mashup, должны были взять доступную технологию и найти способы приспособить ее для своих нужд. Было разработано два подхода, позволяющие браузеру извлекать содержимое без перезагрузки страницы: встраивание внешнего транспортного механизма и использование родных браузеру объектов для выполнения транспортных обязанностей.

Помощь извне

Одним из ранних решений стал механизм Microsoft Remote Scripting, который использовал Java™-апплет, обменивавшийся сообщениями в XML-формате с серверными компонентами. Этот подход быстро стал громоздким из-за споров производителей, а также из-за различий в Java Virtual Machine (JVM) и моделях защиты.

Позднее Microsoft создал объект XMLHttpRequest (XHR), разработчики которого ожидали, что он будет использоваться только с Microsoft® Outlook® Web Access (OWA). Этот объект был поначалу доступен только для пользователей Windows® Internet Explorer® и использовался нечасто, пока через несколько лет его не реализовали Mozilla и Safari. Первоначально внешний объект Microsoft ActiveX® в современных реализациях является родным объектом браузеров. Несмотря на свое название, XHR-объект может передавать данные в любом формате и не ограничен только корректным XML.

Многие разработчики используют функциональные возможности XML-коммуникации программы Macromedia Flash для создания встраиваемых компонентов, взаимодействующих с сервером. Объекты XMLSocket и flex.net.socket предоставляют возможности, аналогичные XHR, но с дополнительными возможностями управления коммуникацией и синтаксического анализа XML.

Внутренняя работа

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

• Использование скрытого элемента iframe для загрузки внешнего содержимого: Затем к iframe обращаются через DOM для извлечения содержимого из загруженного документа. Можно указать любые параметры в URL строки запроса или динамически создать форму, передающую данные в сервис с iframe в качестве назначения. Этот метод поддерживается разнообразными современными и более старыми браузерами.
• Использование элемента img для передачи запросов на получение содержимого: Сервер выполняет свою задачу, используя параметры из URL строки запроса, а затем возвращает закодированное содержимое в куки. Этот метод ограничен в количестве данных, которыми можно обмениваться, поскольку строка запроса и куки ограничены в размерах.
• Динамическое создание элемента script в DOM текущей страницы: При загрузке предоставленный сервером код выполняется немедленно. Сервер использует параметры из URL строки запроса.

Ссылки на подробную информацию по этим программам и техническим приемам приведены в разделе "Ресурсы".

В начало

Преодолевая границы

Большинство из доступных технологий для асинхронного извлечения содержимого наследует модель защиты JavaScript, которая позволяет сценариям взаимодействовать только с элементами, находящимися на том же сервере, что и страница, которой принадлежит сценарий. Это политика Same Origin Policy (политика единого происхождения), которую реализуют все браузеры.

Для того чтобы Web-страница извлекала содержимое из сторонних источников, нужно обмануть политику Same Origin Policy. Обычно используемым исключением, не ограниченным политикой Same Origin Policy, является тег <script>, посредством которого элемент <script> добавляется в дерево объектов DOM страницы, заставляя ее загружать и выполнять код, находящийся в URL, указываемом атрибутом src этого элемента.

Использование тега <script> для выполнения сценариев нескольких сайтов предполагает высокий уровень доверия между всеми участвующими сайтами, поскольку все эти сценарии выполняются в одном и том же контексте и, таким образом, могут получить доступ к информации и куки других сайтов.

В начало

Защищенность или масштабируемость: Нельзя иметь то и другое одновременно

За обходные пути, широко используемые для обеспечения возможности работы Ajax mashup-приложений, приходится чем-то платить. Преодолевая границы ограничений браузеров, вы воздействуете на другие аспекты общего функционирования приложения. При этом приложение становится либо менее защищенным, либо менее масштабируемым.

Защищен, но масштабируем?

При ограничении политикой браузера Same Origin Policy, тот же сервер, на котором размещено приложение, должен взять на себя работу по извлечению стороннего содержимого и передачи его клиенту. Сервер выступает в качестве клиента стороннего сервиса в дополнение к своим обычным функциям.

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

Масштабируем, но защищен?

Использование тега <script> для обхода политики Same Origin Policy позволяет клиенту извлекать содержимое из сторонних источников. Эта функциональная возможность устраняет серверную проблему масштабируемости, поскольку каждый дополнительный клиент сам забирает содержимое.

Преимущества масштабируемости с тегом <script> предоставляются путем обмана модели защиты Same Origin Policy, что может сказаться на уязвимости для атак:

• Становится возможен межсайтовый доступ к куки: Сценарии одного сайта могут получить доступ к куки другого сайта.
• Нет возможности контролировать извлеченный код на безопасность перед его выполнением: Код выполняется сразу после загрузки.

В начало

Возможные решения

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

Здесь и сейчас

Недавно разработанная методика извлечения содержимого использует взаимодействие между сценарием страницы и скрытым iframe через идентификатор фрагмента URL его атрибута src (часть URL, которая находится после знака #). Сценарии на родительской странице и во встроенном iframe могут устанавливать идентификаторы фрагмента друг друга, несмотря на то, что имеют разное происхождение. Между сценариями поддерживается согласованный протокол взаимодействия, управляемый JavaScript-таймерами, которые периодически выполняют процедуры для проверки изменений в индикаторах фрагментов.

Поскольку сценарии должны знать адреса друг друга и договориться между собой о протоколе, доверие гарантируется. Так как каждое взаимодействие сервера является локальным для каждого компонента и отделенным от межсценарного взаимодействия, куки не показываются.

Хотя это решение все еще не совершенно (например, оно основывается на аномалии, которая не является запланированным поведением, и опрос изменений хуже активизации события в ответ на изменение), оно лучше остальных решений подходит к реализации естественного для браузера, защищенного, встроенного в страницу, междоменного взаимодействия.

Примечание: Джеймс Бурке (James Burke), разработчик из AOL Developer Network, первым начал использовать методику передачи идентификатора фрагмента и встроил ее в последние версии библиотеки Dojo Toolkit JavaScript.

Перспективы

Производители браузеров и сообщество разработчиков обсуждают несколько возможных путей изменения элементов среды браузера, для того чтобы приспособить их для работы с Ajax mashup-приложениями. Web Hypertext Application Technology Working Group (WHATWG) предложила в разделе 7.3 своего документа Web Applications 1.0 Working Draft механизм, называемый Cross Document Messaging. Браузер Opera уже реализует эту функциональность. Данный механизм определяет метод взаимодействия между DOM-объектами из различных доменов, позволяющий получателю выбирать, на какие сообщения отвечать, основываясь на их происхождении.

Ян Хиксон (Ian Hickson) (работавший в Opera, а сейчас в Google) предложил межсайтовые расширения существующего объекта XMLHttpRequest. Его предложение заключается в нескольких изменениях способа выполнения запросов, включая ограничения в управлении заголовком и механизм управления доступом.

Дуглас Крокфорд (Douglas Crockford), пропагандист JavaScript и разработчик в Yahoo!, является одним из общепризнанных в мире экспертов в языке JavaScript. Можно найти множество презентаций и статей, объясняющих сложные приемы работы с JavaScript на его персональном Web-сайте и на Yahoo! Developer Network. Еще одной инициативой, которую продвигает Крокфорд, является JSON, формат обмена данными, который широко используется в Ajax-приложениях, в основном потому, что он готов к работе в JavaScript и менее многословен по сравнению с XML. Крокфорд внес два предложения по встраиванию в браузеры элементов для mashup-приложений.

Нереализованные предложения

Существует несколько предложений, помогающих решить эту задачу:

• JSONRequest: Браузеры реализуют новый объект, который работает почти так же, как существующий объект XMLHttp, но с несколькими изменениями:
  • JSONRequest не ограничивался бы политикой Same Origin Policy.
  • Использовался бы минимальный набор HTTP-заголовков для уменьшения общего размера запросов.
  • Не передавались бы куки, что устранит проблемы межсайтовых куки.
  • JSONRequest принимал бы только корректный JSON-текст, что гарантировало бы невозможность передачи для выполнения необработанного (raw) исполняемого кода.
  • После аварийного прекращения взаимодействия вводятся случайные задержки перед повторными попытками для препятствия проведению атак определенного класса.
  • Каждый запрос возвращал бы упорядоченный идентификатор, что позволило бы легко связывать асинхронные ответы с их оригинальными запросами.
  • Специальная поддержка дуплексных соединений позволила бы серверу асинхронно инициировать взаимодействия через открытый коммуникационный канал.
• Тег <module>: Новый HTML-тег разделяет страницу на набор модулей, защищенных друг от друга, но способных надежно взаимодействовать:
  • Тег <module> мог бы иметь возможность обращаться к сторонним ресурсам, не будучи ограниченным политикой Same Origin Policy.
  • Совместное взаимодействие между страницей и модулем было бы возможно только через специальные интерфейсы. Модули не могли бы взаимодействовать друг с другом, а только со страницей. Страница может содействовать взаимодействию между модулями.
  • Взаимодействие было бы ограничено корректным JSON-текстом, в отличие от взаимодействия JavaScript-объектов, могущего вызвать уязвимость в системе защиты через присоединенный код.
  • Предлагаются ограничения для запрета модулям и страницам интерферировать с выводом друг друга, вызывая проблемы защиты.
• Заголовок ограничений содержимого (Content restrictions header): Джервейс Маркхэм (Gervase Markham) предлагает спецификацию заголовка ограничений содержимого, который позволил бы авторам высказывать все пожелания о том, как их содержимое должно взаимодействовать с содержимым других сайтов. Совместимая реализация передавала бы этот заголовок, содержащий строку политики.
• W3C Access Control List (ACL) System: W3C ACL System могла бы использоваться как модель для основанной на ACL системы по управлению доступом к HTTP-ресурсам в Ajax mashup-приложениях.
• Cross-domain.xml: Flash-объекты ищут файл cross-domain.xml на сервере перед попыткой получить доступ к указанному в них URL. Этот файл указывает, какие сайты могут размещать приложения, имеющие доступ к сервисам, предоставляемым на этом сервере. Многие провайдеры Web-сервисов уже реализовали этот файл.

Ссылки на подробную информацию по этим предложениям приведены в разделе "Ресурсы".

В начало

Помогите определить будущее

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

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

Ссылки для начала работы можно найти в разделе "Ресурсы" данной статьи.

Ресурсы

Научиться

• Оригинал статьи "Shaping the future of secure Ajax mashups" (EN).
  
  
• Раздел XML на developerWorks : всеобъемлющая информация по XML в разделе XML на сайте developerWorks.
  
  
• История XMLHTTP: история от Алекса Хопмана (Alex Hopmann) о возникновении XMLHTTP.(EN)
  
  
• DOM Level 3 Load and Save Specification: спецификация W3C о том, как программы и сценарии могут динамически загружать содержимое XML-документа в DOM-документ и сериализировать DOM-документ в XML-документ.(EN)
  
  
• Same Origin Policy: на Web-сайте Mozilla размещена информация о данной политике, предназначенной для запрета документам или сценариям, загруженным из одного источника, получать или устанавливать свойства документа из другого источника.(EN)
  
  
• Межсайтовые сценарии (Пол Ли (Paul Lee), developerWorks, сентябрь 2002): дополнительная информация по данной проблеме.(EN)
  
  
• "Удаленное выполнение сценариев с использованием сервлетов" (EN) (Эрик Хатчер (Erik Hatcher), developerWorks, февраль 2001) и "Передача форматированных сообщений между клиентом и сервером с использованием асинхронной системы обмена сообщениями" (EN) (Эрик Хатчер (Erik Hatcher), developerWorks, май 2001): в этих статьях приведена информация о данных технических приемах.(EN)
  
  
• Ajax Transport Layer Alternatives: заметки Брента Эшли (Brent Ashley), доступные на его Web-сайте.(EN)
  
  
• Iframe/fragment identifier discovery: дополнительная информация об идентификаторах фрагментов в оригинальном блоге Джеймса Бурке (James Burke).(EN)
  
  
• Реализация Dojo Toolkit: как Dojo Toolkit реализует метод передачи идентификатора фрагмента.(EN)
  
  
• Cross-document messaging: дополнительная информация о предложении WHATWG.(EN)
  
  
• Межсайтовый XMLHttpRequest : обновленное предложение Яна Хиксона (Ian Hickson).(EN)
  
  
• JSONRequest и тег <module> : предложения Дугласа Крокфорда (Douglas Crockford) о решении проблем защиты mashup-приложений.(EN)
  
  
• Заголовки ограничения содержимого: предложение Джервейса Маркхема (Gervase Markham) о способе, позволяющем браузерам отличить легитимные сценарии от злонамеренных.(EN)
  
  
• ACL System: информация о динамической, пятиуровневой системе управления доступом от W3C, включающей ACL-хранилище и механизмы запросов плюс доступность и возможность использования этих данных в семантической сети (semantic Web).(EN)
  
  
• Объект XMLSocket и файлы cross-domain.xml: информация о том, как объект XMLSocket и файлы междоменной политики позволяют взаимодействие между компьютером, на котором работает Flash Player, и другим сервером, указанным при помощи IP-адреса или доменного имени.(EN)
  
  
• Сертификация IBM XML: информация о том, как получить сертификат IBM-Certified Developer по XML и смежным технологиям.(EN)
  
  
• Техническая библиотека по XML: в разделе developerWorks XML размещено множество технических статей и советов, учебных руководств, стандартов и книг IBM Redbooks.
  
  
• Технические события и Web-трансляции developerWorks: следите за новинками технологии.(EN)
  
  

Получить продукты и технологии

• Пробное программное обеспечение IBM: разработайте ваш следующий проект, используя пробное программное обеспечение, доступное для загрузки непосредственно с developerWorks.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• The OpenAjax Alliance: помогите определить будущее Ajax вместе с этой отраслевой группой, пропагандирующей Ajax.(EN)
  
  
• Ajaxian: замечательный ресурс по разработке Ajax-приложений и интерфейсных виджетов.(EN)
  
  
• Дискуссионные форумы XML: примите участие в форумах, посвященных XML.(EN)
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Смешивание при помощи Ajax
• Круглые гвозди, квадратные дырки
• Преодолевая границы
• Защищенность или масштабируемость: Нельзя иметь то и другое одновременно
• Возможные решения
• Помогите определить будущее
• Ресурсы
• Об авторе
• Комментарии