Solicitação de CORS com Preflight e redirecionamento: não permitido. Soluções alternativas?

Eu estou projetando uma API que permite ao usuário autenticar (usando tokens) e que contém redirecionamentos dentro do mesmo domínio. Agora, para um pedido não autenticado em um nó de extremidade que retorna 303,

GET /documents/123 --> 303 redirect to `/documents/abc` GET /documents/abc --> 200 

tudo funciona bem.

Vamos fazer uma solicitação autenticada para o mesmo terminal no qual o header de Authorization é enviado. Isso faz da solicitação uma solicitação preflighted e o navegador faz uma solicitação OPTIONS comprovação, ou seja,

 OPTIONS /documents/123 --> 204 (everything okay, please proceed) GET /documents/123 --> 303 redirect to `/documents/abc` 

Neste ponto, em vez de GET ting o recurso real em /documents/abc , o navegador gera

 XMLHttpRequest cannot load http://localhost:8000/people/username/nschloe. The request was redirected to 'http://localhost:8000/people/YDHa-B2FhMie', which is disallowed for cross-origin requests that require preflight. 

Este comportamento está de acordo com o padrão :

7.1.5 Solicitação de origem cruzada com comprovação

Se a resposta tiver um código de status HTTP que não esteja no intervalo 2xx

Aplique as etapas de erro da rede.

Isso parece significar que não é possível fazer redirecionamentos para resources autenticados, mesmo se o redirecionamento estiver no mesmo domínio ( localhost ).

Isso pode realmente ser verdade? Existe uma solução comum?

O padrão original impede o redirecionamento após uma pré-impressão CORS bem-sucedida. Citando § 7.1.5.3 :

Este é o pedido real. Aplique as etapas de solicitação e observe as regras de solicitação abaixo ao fazer a solicitação.

  • Se a resposta tiver um código de status HTTP de 301, 302, 303, 307 ou 308, aplique as etapas de erro de cache e de rede.

Devido aos seus esforços (obrigado!), Em 4 de agosto, o padrão foi atualizado para permitir o redirecionamento após a verificação bem-sucedida do preflight do CORS.

Até que os navegadores alcancem, as únicas opções viáveis ​​parecem ser uma ou uma combinação de:

  1. O problema redireciona apenas para solicitações simples .
  2. Emita um redirecionamento 305 , com seu próprio URL no header ” Location ” como o “proxy”. Esteja preparado para suporte limitado ao navegador, pois o 305 é obsoleto.
  3. Faça um falso “redirecionamento”:
    • retornar HTML com meta refresh e / ou alteração de Location Javascript.
    • retornar HTML que tenha um iframe preenchimento de viewport com o destino de redirecionamento como a origem do iframe.
    • exibir um link que o usuário deve clicar para acessar o conteúdo.