Прозрачное перемещение ресурсов с поддержкой CORS с перекрестным перенаправлением - PullRequest
0 голосов
/ 26 сентября 2018

Я хочу получить доступ к службе REST, которая защищена CAS, работающим в другом домене.Это означает, что мне нужно сделать запрос к конечной точке входа в систему CAS и перенаправить меня к службе назначения.Здесь есть десятки вопросов о , почему перенаправления CORS не срабатывают, но я пока не нашел ответа на вопрос , как действительно заставить его работать.

Я нашел некоторые Руководство W3C по работе с CORS , которое включает в себя отдельную тему по теме:

Чтобы сделать возможным прозрачное перемещение ресурсов с поддержкой CORS, доступ к которым осуществляется через простые запросы, требуется работа и координация со стороны серверов.Например, ресурс на https://old.example.com/resource может ответить на запрос CORS с помощью учетных данных с перенаправлением на https://new.example.com/resource?originalOrigin=...&credential=..., который будет иметь полномочия для доступа к ресурсу в параметре URL вместо заголовков Cookie и Origin,Серверу на https://new.example.com потребуется пользовательская логика для распознавания и проверки подлинности этих параметров и выполнения соответствующей авторизации перед возвратом заголовков Access-Control-Allow пользовательскому агенту.

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

Как говорится в тексте, перенаправитель (old.example.com в приведенном выше) должензапрашивать учетные данные.Но, если я позвоню fetch(url, {credentials:"include"}), учетные данные также будут включены при перенаправлении (new.example.com, выше).Поскольку я советую fetch включать учетные данные, окончательный URL-адрес, загруженный браузером, должен отправить соответствующий заголовок ACA-Origin, но поскольку он является целью перенаправления, источником второго запроса будет null.

Чтобы сделать возможным рабочий процесс, предложенный W3C, мне нужно было бы указать браузеру отправлять учетные данные на old.example.com, но как только он перенаправит вас на new.example.com, запросите его без учетных данных / нет.режим Cors.Насколько я знаю, это невозможно - первоначальный запрос и все последующие перенаправления получают одинаковые параметры выборки.Я что-то пропустил?Есть ли другой способ сделать это?

1 Ответ

0 голосов
/ 26 сентября 2018

Ты ничего не пропустил.Вам нужно обновить всех вызывающих абонентов, если вы не хотите разрешать запросы с учетными данными на новом месте.

...