Обход той же политики происхождения для аутентифицированных запросов XmlHttpRequests

Question

У меня есть веб-сайт на foo.com, обслуживающий PageA.

PageA, в котором есть некоторый JQuery, который через XmlHttp запрашивает некоторые данные JSON из экземпляра CouchDb, расположенного в bar.com.

Насколько я понимаю, та же политика происхождения предотвращает это, но использование JSONP должно обойти это ограничение (я полагаю, что CORS в конечном итоге покроет этот вариант использования).

Сервер, стоящий за foo.com, имеетдоверенное соединение с базой данных на bar.com.

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

Учитывая это, существует ли любой способ, которым я могу аутентифицировать пользователя для использования CouchDB на bar.comс foo.com с использованием любого из доступных механизмов аутентификации для CouchDB (OAuth, cookie и Basic)?

Редактировать: могу ли я, например, вернуть учетные данные пользователя для bar.com из foo.com (получено по доверенной ссылке), которые затем устанавливаются на стороне клиента в HTTP-заголовке XmlHttpRequest для базовой аутентификации с bar.com.Конечно, все сделано через TLS (... или это кошмар безопасности?)

Answer 1

Из моего POV даже JSONP представляет угрозу безопасности - поэтому я бы просто не пошел по этому пути ...

Чтобы достичь того, о чем вы просите, я вижу два варианта (оба могут быть настроены для работы с SSL, если это необходимо!):

• написать пользовательский веб-сервис / REST / SOAP / все, что работает на foo.com и взаимодействует от вашего имени с bar.com для аутентифицированных клиентов

• использует «универсальный http-прокси», который работает на foo.com и отображает bar.com таким образом, что ваше приложение / страница работает так, как будто CouchDB работает на bar.com для аутентифицированных клиентов

Answer 2

У меня была такая же проблема относительно политики происхождения в xhr.У меня был веб-сайт, и я хотел заполнить содержимое автозаполнения данными JSON с другого сервера, работающего под управлением CouchDB.

Существует 2 способа:

1. JSONP - это прекрасно работает
2. прокси CouchDB через основной веб-сервер - это прекрасно работает с точки зрения клиента, поскольку все находится на одном хосте.Это также делает SSL выполнимым.

Что касается совместного использования сеанса входа в систему из CouchDB и другого сервера приложений, я не знаю, как это сделать, не прибегая к базовой HTTP-аутентификации, которая на самом деле неэто безопасно.Вероятно, лучше позволить серверу приложений выступать в роли посредника b / t-клиента и CouchDB.

Другое преимущество посредника сервера приложений заключается в том, что в одной базе данных CouchDB могут быть документы для нескольких пользователей.Напротив, если клиент обращается к CouchDB напрямую, вам, вероятно, нужно создать отдельную базу данных для каждого пользователя через фильтрованную репликацию, чтобы один пользователь не мог просматривать документы другого пользователя.

Answer 3

Насколько я понимаю, вы хотите использовать JSONP с foo.com для отправки запросов на bar.com, в то время как хотите, чтобы bar.com могла узнать, аутентифицирован ли этот запрос на foo.com или нет.

Это похоже на вход на foo.com и передачу подлинности на bar.com.

Предполагая, что XMLHttpRequest может запомнить идентификатор сеанса в файле cookie остальных запросов, как насчет использования одноразового пароля (фактически, случайной строки, мы можем назвать его токеном), который сделал вызов bar.com со страницы, сгенерированной foo.com после входа, изображена как показано ниже:

login request -> foo.com -> XHR(bar.com, OTP) -> bar.com
cookie updated with an active session id <- bar.com
XHR(bar.com, CounchDB) -> bar.com successfully

Таким образом, если foo.com и bar.com могут общаться в частном порядке (и безопасно!), Foo.com может сгенерировать OTP и передать его на bar.com, чтобы bar.com знал, что только действительный пользователь может знать его и поэтому может обрабатывать идентификатор сеанса как аутентифицированный.

Альтернативные курсы:

1. Если файл cookie, используемый XMLHttpRequest для bar.com, не сохраняется между запросами, один и тот же OTP должен передаваться в каждом запросе.
2. bar.com должен предоставить сервис для мониторинга авторизации авторизации от foo.com для вновь добавленного OTP. У него должен быть механизм тайм-аута для аннулирования старых токенов.
3. bar.com также может потребоваться предоставить услугу удаления аутентификации, чтобы предотвратить риски при использовании общедоступных компьютеров.

Answer 4

Вы можете получить информацию о потоке сервера аутентификации Facebook, заменив клиента своим клиентом, сервер для foo.com и Facebook для bar.com.Посмотрите на http://developers.facebook.com/docs/authentication. Таким образом, клиент должен был пройти аутентификацию для использования данных с bar.com (конечно, в скрипте, загруженном с bar.com, но вы можете передавать данные в callback с foo.com, если я не ошибаюсь).