Парализованный нерешительностью (в любой момент времени в OSCON есть буквально три разных сеанса, которые я бы посчитал необходимыми для просмотра), я обратился к межсайтовому Ajax для разработчика Plaxo Джозефа Смарра : проблемы и методы создания многофункциональных мэшапов Web 2.0 Главным образом потому, что я выступаю с докладом на ту же тему на веб-сайте Directions в сентябре. Слайды будут доступны в блоге Plaxo .
Mashups, если вы жили в безвыходном положении, — это веб-приложения, созданные путем объединения сервисов, предоставляемых несколькими специализированными веб-приложениями, обычно использующими AJAX в качестве клея. Одной из основных проблем, с которой сталкиваются разработчики гибридных приложений, является политика одного и того же происхождения, которая запрещает JavaScript на одном сайте связываться с другими сайтами в качестве меры безопасности. Чтобы гибридные приложения действительно работали, разработчики должны найти способ обойти это ограничение.
История до сих пор…
Существует ряд хорошо понятных решений этой проблемы, но у всех есть свои проблемы. Поскольку политика одного и того же происхождения влияет только на браузер, прокси-серверная сторона является наиболее очевидным подходом, когда ваш JavaScript связывается с вашим веб-приложением, которое затем выполняет запрос к службе в другом домене. К сожалению, это делает ваш сервер узким местом, а не позволяет каждому клиенту напрямую связываться со службой.
Другой вариант — использовать Flash-ролик в качестве прокси. Flash имеет аналогичную политику того же происхождения в отношении запросов, которые она делает, но эта политика может быть подавлена, если служба назначения предоставляет файл crossdomain.xml в своем домене. Если Flash видит этот файл и в нем содержится список домена, который хочет сделать запрос, междоменный запрос разрешается. Конечно, Flash — это запатентованная, не основанная на стандартах технология, которая может не подойти вам.
Более сложное решение, называемое JSON-P, динамически добавляет элемент script на страницу для выполнения запроса. Теги <script> не подчиняются политике одного и того же происхождения, поэтому атрибут src может указывать на другой домен, и запрос будет выполнен без жалоб.
Поскольку браузер ожидает получения и выполнения кода JavaScript из этого запроса, это именно то, что должна возвращать служба, вызываемая таким образом, но вам нужен этот код, чтобы сделать что-то значимое для вашего приложения. Наиболее распространенный способ поддержать это — отправить в строке запроса имя функции обратного вызова в вашем коде, которую служба может использовать для вызова функции в ответ на ваш запрос.
Проблемы с JSON-P в том виде, в каком он существует в настоящее время, включают отсутствие обработки ошибок, требование, чтобы ваш запрос был выполнен через HTTP GET, и возможность того, что служба может вернуть вредоносный код, который может выполняться внутри вашего приложения (например, кража чувствительные значения cookie).
Что нового?
Plaxo хотел создать систему , которая позволяла бы вам выбирать адреса электронной почты из вашей адресной книги Gmail и вставлять их в текстовое поле на стороннем сайте, просто нажав кнопку на этом стороннем сайте (и указав свой логин Gmail). учетные данные с первого раза). Для этого потребуется, чтобы сторонний сайт имел междоменный доступ к Gmail, и ни одно из перечисленных выше решений не сработало бы.
«Червоточина JavaScript» — это то, что Plaxo называет разработанным решением, и хотя эта техника гениальна, она также довольно извилистая, настолько сложная, что ее трудно передать словами — но я попробую:
Поставщик службы, такой как селектор адресной книги Plaxo, предоставляет файл HTML, который необходимо добавить на любой сайт, который использует службу. Этот файл предоставляет механизм обратного вызова для службы для возврата данных на запрашивающий сайт.
Когда служба вызывается (например, браузер открывает селектор адресной книги из Plaxo во всплывающем окне), и пользователь заканчивает взаимодействие с ним (например, пользователь выбирает один или несколько контактов и нажимает «ОК»), всплывающее окно службы -up окно загружает HTML-файл обратного вызова с запрашивающего сайта в iframe . HTML-файл обратного вызова, в свою очередь, содержит <script> который запрашивает результаты вызова службы (например, контакты, выбранные пользователем) из Plaxo с использованием технологии JSON-P, описанной выше. Поскольку файл HTML размещен на запрашивающем сайте, JavaScript, возвращенный в ответе, может записать эти результаты на исходную страницу этого сайта (например, вставить выбранные адреса электронной почты в соответствующее поле формы).
Смарр отметил, что Plaxo проводит определенную работу по созданию стандарта «обобщенной червоточины JavaScript», который другие службы могут легко принять, устраняя необходимость для каждого сервиса предоставлять свой собственный HTML-файл обратного вызова для установки владельцами сайта. Это решение будет включать возможность для владельцев сайтов предоставлять список доверенных доменов, чьи сервисы смогут использовать обратный вызов для обновления страниц сайта (например, вставлять адреса электронной почты в форму) по запросу.
Червоточина JavaScript не является панацеей — она страдает от тех же недостатков, что и JSON-P, поскольку она построена на этом методе, — но это, безусловно, самое изящное (если не единственное) решение для служб, которым необходимо изменить страницу запрашивающего сайта. после некоторого взаимодействия пользователя со службой.
Куда отсюда?
Если мы думаем о будущем сейчас, возможно, мы сможем получить платформу, которая не потребует от нас «проникнуть в наш собственный дом» для создания коллажей. Смарр считает (и я полностью согласен), что разработчики должны обсуждать эти проблемы сейчас, чтобы сформировать платформы будущего, чтобы они отвечали потребностям разработчиков гибридных приложений, не ставя под угрозу строгую — но невидимую для пользователя — модель безопасности, которая существует сегодня. ,
На столе уже есть ряд предложенных решений. Одна из возможностей — установить стандартный способ определения доверительных отношений между сайтами. Flash делает это с помощью crossdomain.xml , веб-службы делают это с помощью сертификатов и белых списков IP-адресов, и обобщенное решение для червоточины JavaScript также делает это. Но не нарушит ли это свободу гибридных приложений, которые в настоящее время позволяют разработчикам придумывать идею и «просто делать это»? Формализованные доверительные отношения породят контракты на обслуживание и лицензионные соглашения, которые убьют дух коллажей.
Другие идеи, представленные в таблице, включают предлагаемые усовершенствования браузера, такие как ContextAgnosticXmlHttpRequest Криса Холланда , который в отличие от текущего объекта XMLHttpRequest разрешает междоменные запросы, но не отправляет заголовки cookie или HTTP-аутентификации и может подключаться только к серверам, которые отправляют X-Allow-Foreign-Hosts Заголовок X-Allow-Foreign-Hosts в их HTTP-ответах. Предложенный Дугласом Крокфордом JSONRequest будет работать с аналогичными ограничениями, но будет специфичным для сервисов в формате JSON. Но ограничения, предлагаемые этими решениями, могут зайти слишком далеко.
Какое бы решение вы ни предпочли, реальное сообщение заключается в том, что будущее AJAX в целом и гибридных приложений, в частности, широко открыто, и вам необходимо принять участие в процессе определения его эволюции. Простых ответов пока нет, и эти проблемы не исчезнут в ближайшее время. Но, пожалуй, самое главное, разработчики браузеров слушают больше, чем когда-либо, и мы должны сказать им, что мы, как разработчики, хотим.