Почему мои конечные точки не передают заголовки/файлы cookie и не отвечают, как ожидается, в Clojure, используя кольцо?

Я хочу перенаправить с конечной точки API на другую конечную точку, передавая заголовки и файлы cookie.

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

(GET "/the-endpoint"
     request
     (-> (response/redirect "/another-endpoint")
         (response/header "Authorization" (str "Bearer " "some-token"))
         (response/set-cookie "access_token" "some-token")))

Обратите внимание, что я поместил токен и в заголовок, и в файлы cookie для целей тестирования, поскольку ни заголовок, ни файлы cookie не передаются в /another-endpoint.

У меня есть простой GET для другой конечной точки, который пока возвращает ответ с глупым телом.

Я смотрю значения заголовков и файлов cookie на вкладке «Сеть» в Chrome DevTools. Я испытываю странное поведение в этом обработчике, из-за чего тело ответа загружается Chrome, а не отображается в браузере.

(GET "/another-endpoint"
     request
     (response/response "something random to be used as the body for now"))

Я вижу запрос в сети, который показывает статус 200, но заголовок запроса и файлы cookie, через которые я прошел, не были установлены. Я думал, что это проблема CORS, поэтому я сделал перенаправление на тот же API и испытал такое же поведение.

Я использую:

[ring/ring-core "1.6.3"]

Собственно, что я хочу знать:

  1. Почему заголовок Authorization и файл cookie access_token не передаются /another-endpoint?
  2. Почему ресурс /another-endpoint загружается Chrome, а не отображается в браузере?

Что я пытаюсь сделать:

  1. Пользователь входит на веб-сайт и нажимает кнопку, чтобы что-то сделать.
  2. Эта кнопка позволяет перейти к конечной точке API, которая создаст файл jwt.
  3. API необходимо перенаправить на внешний API с jwt в заголовке для автоматической аутентификации.
  4. После аутентификации пользователю необходимо беспрепятственно перейти к панели управления внешнего веб-сайта, чтобы он мог продолжить (без ручного входа в систему).

Прямо сейчас я тестирую все на том же API.


person Clarice Bouwer    schedule 11.11.2019    source источник
comment
(2) Мне нужен тип контента. По умолчанию я заметил, что установлено значение application/edn; charset=utf-8 загружается вместо отображения в браузере"> stackoverflow.com/questions/35548372/   -  person Clarice Bouwer    schedule 11.11.2019
comment
Chrome не знает, как отобразить edn, и будет считать это файлом и сохранять его.   -  person Jochen Bedersdorfer    schedule 11.11.2019
comment
Да, это имеет смысл. :)   -  person Clarice Bouwer    schedule 11.11.2019
comment
По сути, проблема в том, что вы не можете установить заголовки в перенаправлении, кроме самого заголовка Location. Это ограничение HTTP, которое на самом деле имеет смысл, если вы думаете о том, что происходит: сообщение клиенту сделать новый запрос. Клиент сохраняет контроль над тем, какие заголовки он собирается отправить.   -  person skillet-thief    schedule 12.11.2019
comment
Итак, если я хочу передать файлы cookie, сеанс и заголовки на новую страницу, нужно ли мне вместо этого перенаправлять от клиента (а не на стороне сервера с использованием кольца)? Когда я выполняю перенаправление на стороне сервера на страницу в том же домене, ни один из них не передается на перенаправленную страницу (если только я не проверил ее неправильно).   -  person Clarice Bouwer    schedule 12.11.2019
comment
Когда клиент выполняет перенаправление, он будет использовать любые файлы cookie и/или учетные данные аутентификации, которые у него уже есть, куда бы он ни был перенаправлен. Поэтому, если вы перенаправляете на тот же домен (или субдомен), то перенаправленная страница должна получить те же файлы cookie и учетные данные. Просто в ответе перенаправления у вас нет никакого контроля над тем, как делается второй запрос. (Технически клиент может решить даже не следовать перенаправлениям.)   -  person skillet-thief    schedule 13.11.2019