Tente isto:
redirect "https://#{request.host}/<path>"
Sinatra é leve, não tem nenhuma detecção para isso por padrão, eu acho.
Eu tenho um aplicativo Sinatra em execução no nginx (usando thin como um back-proxy) e estou usando as instruções redirect '/<path>'
no Sinatra. No entanto, quando eu acesso o site em https, esses redirecionamentos me enviam para http://localhost/<path>
em vez de https://localhost/<path>
como deveriam.
Atualmente, o nginx passa o controle para thin com este comando proxy_pass http://thin_cluster
, onde thin_cluster
é
upstream thin_cluster { server unix:/tmp/thin.cct.0.sock; }
Como posso corrigir isso?
Tente isto:
redirect "https://#{request.host}/<path>"
Sinatra é leve, não tem nenhuma detecção para isso por padrão, eu acho.
Você deve conseguir isso com a diretiva proxy_redirect . Se proxy_redirect default
não funcionar (deve ser a configuração padrão), tente algo assim:
proxy_redirect http://localhost/ https://localhost/;
url()
determina se é necessário usar HTTP ou HTTPS com base nas informações da classe Sinatra::Request
, derivada da classe Rack::Request
. Quando colocado atrás de um proxy reverso como Nginx, o proxy reverso tem que injetar alguns cabeçalhos dizendo a Rack (e, portanto, a Sinatra) como o mundo o vê. Infelizmente, o Nginx não define esses cabeçalhos por padrão, então teremos que fazer isso manualmente.
O rack determina se é ou não HTTPS com base nos cabeçalhos enviados pelo Nginx. Infelizmente, o Nginx não define esses cabeçalhos por padrão, então você terá que especificá-los manualmente.
Vejamos um exemplo, configuração problemática.
# Bad configuration
location / {
proxy_pass http://127.0.0.1:9000;
}
Sinatra nem sabe que está atrás de um proxy reverso, então url('/robots.txt')
gerará http://127.0.0.1:9000/robots.txt
. O Nginx tentará corrigi-lo automaticamente com a substituição proxy_redirect
, resultando em http://hostname/robots.txt
. Eu acho que a razão pela qual isso não conserta o esquema é porque algumas pessoas gostam de misturar as solicitações HTTP e HTTPS, mas não tenho certeza.
Aqui está uma cláusula proxy de exemplo da minha própria configuração Nginx.
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-SSL on;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://127.0.0.1:9000;
}
X-Forwarded-SSL: on
diz ao Sinatra que ele está atrás do HTTPS e não do hTTP, e a configuração Host: $http_host
diz ao Sinatra o nome do host do servidor real. Agora, url('/robots.txt')
produzirá https://hostname/robots.txt
. Como não precisamos do Nginx para executar substituições em nossos redirecionamentos, eu o desativei explicitamente com proxy_redirect off;
. (O X-Forwarded-For
é apenas para que Sinatra possa descobrir o endereço IP do usuário também.)
Um benefício adicional em confiar no Sinatra para fazer tudo corretamente, ao invés da cláusula proxy_redirect
do Nginx, é que você pode usar a função url()
dentro das views e similares.
X-Forwarded-SSL
é apenas um dos poucos cabeçalhos que você pode definir. HTTPS: on
, X-Forwarded-Scheme: https
e X-Forwarded-Proto: https
devem funcionar bem também. Note que a configuração do esquema para algo como otherproto
não funcionará com o Sinatra, pois ele verifica se é HTTPS ou não e gera a URL com base nesse boleano, em vez de apenas copiar o esquema.
Se você estiver interessado em pesquisar o código sozinho, recomendo estas duas referências como ponto de partida: