Como posso adicionar a autenticação básica a um proxy do apache ao usar cabeçalhos CORS?

Question

Antecedentes

Eu uso o grafana para exibir gráficos de nossas métricas de servidor. O Grafana é um aplicativo JS que, no nosso caso, está obtendo os dados do grafite e armazenando as consultas de pesquisa no elasticsearch. Todos os três serviços têm seu próprio vhost, apesar de estarem na mesma máquina por enquanto. Por causa das regras JS, adicionei cabeçalhos CORS ao grafite e elasticsearch-vhost. O graphite-vhost é um pedido de roteamento para o WSGI, porque o grafite é um aplicativo python / django. O elasticsearch-vhost é um proxy reverso para encaminhar dados da porta 443 para localhost:9200 . Isso ajuda a não abrir o serviço elasticsearch diretamente para o mundo e também me dá um lugar para adicionar o cabeçalho CORS. Até agora, isso funciona: a grafana pode falar com os dois serviços.

Problemas surgem

Eu adicionei Basic Auth aos anfitriões grafana e grafite. Estes funcionam bem e como esperado. A grafana é capaz de recuperar e exibir os dados.

Ao adicionar Basic Auth ao elasticsearch-vhost, eu me deparo com problemas. Embora eu possa adicionar as configurações de Auth em um <Location / > -block, parece desabilitar os cabeçalhos CORS. Com a autenticação ativada, posso usar o elasticsearch com um navegador ou enrolar.

No entanto, o grafana não pode procurar por painéis configurados no elasticsearch.

A pesquisa parece ser mais complexa que a GET , porque a grafana começa com OPTIONS -request. Isso falha com um erro 401. Curiosamente, a grafana pode e recupera dashboards conhecidos (o que é um simples GET ).

Eu não mencionei uma restrição de métodos HTTP nos cabeçalhos.

Então, para resumir isso:

How can I add basic auth to an apache proxy while using CORS headers?

Se você quiser ver as configurações do apache, por favor, me diga quais partes, eu não quero postar três vhosts de tamanho considerável "só para ter certeza".

    

Answer 1

Eu resolvi isso sempre permitindo OPTIONS -requests. Essas solicitações servem apenas como um "ping" para verificar se o servidor está lá.

<Proxy *>
  Order deny,allow
  Allow from all

  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /path/to/passwords

  # This allows OPTIONS-requests without authorization
  <LimitExcept OPTIONS>
    Require valid-user
  </LimitExcept>

</Proxy>

Uma abordagem mais limpa poderia ser mudar a grafana e como as solicitações são feitas, mas isso resolve o problema imediato sem abrir novas.

Atualmente, isso não piora as coisas do ponto de vista da segurança:

• OPTIONS atualmente não tem um corpo para revelar mais informações
• OPTIONS é idempotente no sentido de que sempre faz nada
• A mera existência do servidor também pode ser verificada com um GET / mais pesado.
• Todos os outros métodos HTTP, mas OPTIONS , estão protegidos por senha