AJAX дилемма перенаправления, как получить URL перенаправления ИЛИ как установить свойства для запроса перенаправления

Question

Во-первых, я работаю в Google Chrome, если это поможет. Вот поведение:

Я отправляю xhr-запрос через jQuery на удаленный сайт (это расширение Chrome, и я установил все настройки для межсайтовых настроек ...):

$.ajax({
    type: "POST",
    contentType : "text/xml",
    url: some_url,
    data: some_xml,
    username: user,
    password: pass,
    success: function(data,status,xhr){
        alert(data);
    },
    error: function(xhr, status, error){
        alert(xhr.status);
    }
});

Устанавливаемый URL возвращает 302 (это ожидается), а Chrome следует перенаправлению (также ожидается).

Новый URL-адрес возвращает запрос учетных данных, которые не извлекаются из исходного запроса, поэтому Chrome отображает диалоговое окно входа в систему. Если я введу исходные учетные данные, я получу ответ об отправленном недействительном запросе (это действительный HTTP-запрос - 200 - удаленному серверу просто не нравится один из заголовков).

При просмотре окна разработчика в Chrome отправляются два запроса. Первый - это исходный URL со всеми настройками, установленными в запросе AJAX. Второй - это URL-адрес перенаправления с методом «GET», ничего из поля «POST» и без учетных данных.

Я в растерянности относительно того, что я могу сделать. Мне либо нужно:

1. Получите URL перенаправления, чтобы я мог отправить второй запрос (xhr.getResponseHeader("Location") НЕ работает),

2. Новый запрос на перенаправление сохраняет настройки из исходного запроса или

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

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

Answer 1

Исходя из вашего вопроса, я не совсем уверен, имеете ли вы в виду HTTP-аутентификацию или схему аутентификации на основе форм, и поэтому я рассмотрю оба.

Получить URL перенаправления, чтобы я мог отправить второй запрос (xhr.getResponseHeader («Location») НЕ работает),

При общем способе построения XHR (и в частности в Chrome): XHR не очень гибок и предоставляет относительно высокоуровневый API с тем же поведением, которое браузер выполняет во всех других запросах (адресные строки адреса, исходные URL-адреса изображений, встроенные URL-адреса скриптов), то есть перенаправления обрабатываются прозрачно. Никакие события не будут генерироваться в JavaScript, предупреждающем вас об этом перенаправлении или промежуточных кодах состояния 302/301, вы получите только окончательный код состояния и данные. Поэтому невозможно извлечь заголовок «Местоположение» из ответа, так как окончательный ответ не будет содержать заголовок «Местоположение».

У нового сохраняющего запрос перенаправления настройки из исходного запроса

XHR не предоставляет это в качестве опции, и это будет некорректное поведение по умолчанию. Пример того, почему это должно и не должно происходить по умолчанию:

Acme Corp. предоставляет сервис коротких ссылок для своих сотрудников. Я нажимаю на короткую ссылку, которую я получаю от коллеги, и мне предлагается HTTP-аутентификация службы коротких ссылок Acme. Перенаправление происходит после этой аутентификации. Нет причин, по которым сайт, на который перенаправляется сайт, должен требовать мои учетные данные, и поэтому браузер мог бы некорректно передавать эту информацию (и на самом деле это проблема безопасности). Аналогично, данные POST не следует пересылать, так как они могут быть предназначены только для использования по прямому URL-адресу.

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

К сожалению, по соображениям безопасности и определения стандартов стандартный объект XHR (включая тот, который Chrome использует для межсайтовых запросов в расширениях) не предоставляет никакого способа доступа к окончательному URL-адресу, в котором есть ошибка. Вы можете получить доступ только к окончательному статусу HTTP и любым данным, возвращаемым по окончательному URL.

-

Учитывая это, у вас есть несколько вариантов в зависимости от того, насколько вы контролируете ситуацию:

1) Если у вас есть контроль над сервером перенаправления, рассмотрите возможность включения информации. в ваших AJAX-запросах, указывающих на AJAX-клиента, и пусть сервер вместо этого возвращает данные (то есть объект json), указывающие на необходимость перенаправления.

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

2) Если у вас есть контроль над местом назначения перенаправления, рассмотрите возможность включения URL-адреса получателя при создании страницы с ошибкой аутентификации. Объект XHR будет иметь доступ к этим данным ответа и может их проанализировать для продолжения нового запроса.

3) Если у вас нет контроля ни на сайте перенаправления, ни на сайте назначения, рассмотрите возможность размещения прокси-сервера для обработки запросов и, в частности, для получения 302.

http://myserver/?url=http://redirectsite.com&user=...&pass=...

4) Если ни один из вышеперечисленных вариантов не является опцией, наименее желательным, но все же жизнеспособным вариантом является создание расширения NPAPI для Chrome, которое выполняет собственный код. Это даст вам полный контроль над запросами и позволит вам делать практически все что угодно. Однако обратите внимание, что это происходит за счет более сложной разработки, потенциальных проблем безопасности и меньшей желательности пользователя.

Answer 2

Как уже говорил Раджив М., вы не можете перехватить 302 перенаправления, используя объект XHL или запрос AJAX.

Лучше всего установить прокси-сервер на PHP / ASP или на серверный язык сценариев. PHP-скрипт будет просто следовать 302 перенаправлениям, пока не достигнет конечного пункта назначения. Затем он может отправить окончательный URL-адрес обратно на страницу JavaScript. Теперь будущие запросы AJAX можно отправлять непосредственно на известный окончательный URL-адрес.

Или ...

Ваш PHP-скрипт будет просто служить прокси. Все запросы будут отправлены на этот скрипт PHP.

Или ...

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

Извините - я тоже ненавижу ответы "Вы не можете сделать это", но есть некоторые ограничения JavaScript, которые еще не полностью устранены.

Answer 3

вы не можете использовать windows.location = "newURL"? что раньше работало на меня для перенаправления

Answer 4

Если вы контролируете сервер, вы можете встроить потерянные данные в сам адрес перенаправления. Таким образом, xhr выполняет POST, а затем выполняет GET, а некоторые данные POST кодируются обратно (сервером) в виде параметров GET. Другие решения для меня не подходят ...

Answer 5

Вы можете попробовать тип решения, описанный здесь: Как управлять запросом на перенаправление после вызова jQuery Ajax

Это означает, что на самом деле, заменяя протокол HTTP, вам также необходимо управлять сервером. Все ответы ajax будут в коде 200 (или, по крайней мере, в 3xx, а не в 401/403) с объектом json. и в этом объекте JSON вы можете предоставить специальный код ошибки (почему бы не использовать повторно

Затем вы расширяете функцию jQuery.ajax для захвата этих специальных кодов в вашем ответе json и выполнения новых необходимых запросов. Фактически, автоматический вызов перенаправления jQuery выполняется вами, а не jQuery.

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

Answer 6

К сожалению, нет способа предотвратить автоматическое отслеживание перенаправления xhr или установить учетные данные для места назначения перенаправления (в любом случае это было бы довольно небезопасно, поскольку это позволило бы первому сайту перенаправить учетные данные на любой сайт , а не только тот, который вы хотите получить их).