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: