Перенаправление с https на http? - PullRequest
Новая
       21

Перенаправление с https на http?

4 голосов
/ 19 апреля 2019

Странная проблема здесь.Я использую FullCalendar, чтобы инициировать ajax-запрос к конечной точке на моем сервере.Конечная точка:

https://my_website/events/?start=2019-03-31&end=2019-05-12&_=1555698739056

Обратите внимание, что это явно https.Однако, когда я инициирую запрос (то есть, когда Fullcalendar инициирует запрос), я получаю 301 и перенаправление на конечную точку, отличную от https:

http://my_website/events?start=2019-03-31&end=2019-05-12&_=1555698739056

, которая завершается неудачно, потому чтостраница загружается через https.

enter image description here

Конечная точка работает нормально - когда я загружаю ее в браузер, я получаю ожидаемый вывод json (через https).На этой странице происходят другие запросы ajax, которые работают правильно, и я успешно делаю то же самое с Fullcalendar в другом месте на этом сайте (в другую конечную точку).Это всего лишь один сценарий, который ведет себя неожиданно.

Вероятно, заслуживает внимания тот факт, что он находится в контейнере Docker за обратным прокси-сервером / балансировщиком нагрузки nginx;Конфигурация сайта довольно проста: 

upstream docker {
    server localhost:8701;
    server localhost:8702;
  }

server {
    server_name my_website;
    location / {
      proxy_pass http://docker;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
      # proxy_set_header                HTTP_Country-Code $geoip_country_code;
        proxy_pass_request_headers      on;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/my_website/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/my_website/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = my_website) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name my_website;
    return 404; # managed by Certbot

}

И журнал запроса nginx выглядит так:

134.124.11.91 - - [19 / Apr / 2019: 13: 49:49 -0500] "GET / events /? Start = 2019-04-28 & end = 2019-06-09 & _ = 1555699678658 HTTP / 1.1" 301 0 "https://my_website"" Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, как Gecko) Chrome / 73.0.3683.103 Safari / 537.36 "

Кто-нибудь видит что-то, чего мне не хватает, что может вызвать странное перенаправление 301 на конечную точку без https

Ответы [ 2 ]

4 голосов
/ 23 апреля 2019

Проблема

Это может произойти из-за того, что вы не используете канонические URL-адреса, в то время как ваш бэкэнд применяет такие URL-адреса с помощью этих 301 перенаправлений, тогда как на самом деле он не знает о канонической схеме адресов.

Решение

  • Лучшим решением будет исправить код front-end , чтобы всегда использовать канонические URL-адреса,Например, в приведенных вами примерах есть разница в том, присутствует ли конечная косая черта в вашей конечной точке API.

  • Вероятно, вам следует настроить свой back-end , чтобы правильно знать, что к нему обращаются через https, например, добавить что-то вроде следующего рядом со всеми другими вашими директивами proto_set_header в вашем nginx, который завершает https и передает трафик бэкэнду:

    proto_set_header    X-Forwarded-Proto   $scheme;

Другие мысли

  • Другим решением будет настройка http://nginx.org/r/proxy_redirect для правильного распознавания локальных Location заголовковвозвращается вашим бэкэндом и конвертирует их на лету по мере необходимости;тем не менее, предыдущие два варианта, вероятно, лучше подходят в вашей ситуации.
1 голос
/ 28 апреля 2019

Я не совсем уверен, потому что ваши скриншоты немного противоречивы, но здесь идет:

На скриншоте вашего инспектора мы видим один запрос к https (который отменен) и один к http (который заблокирован из-за смешанных протоколов). Подсказка в отмененном, отменяется, значит, там не было перенаправления, но браузер решил, что больше не нужен запрос . Есть несколько предыдущих вопросов, у которых были похожие проблемы, см. здесь и здесь два примера.

Одна из причин, по которой запрос отменяется, заключается в том, что кнопка / ввод / ссылка, которую вы используете для изменения даты вашего FullCalendar, не только выполняет ajax-запрос, но и выполняет второй http-запрос (из-за формы переноса, href, так далее). Вы не включили html и JavaScript вашей реализации FullCalendar, поэтому я точно не знаю этого, но проверьте, что у вас нет формы, окружающей элемент ввода, или если вы написали свой собственный обработчик событий, сделайте следующее. 

function(e){
  e.preventdefault(); 

  .... // your date switching code here 

  return false;
}

Если вы используете ссылку с атрибутом onclick, обязательно добавьте ...(yourcode);return false; в конце.

Важно: Если моя теория верна, это означает, что строка из вашего журнала на самом деле не соответствует тому, что мы видим в инспекторе, и фактически является перенаправлением с HTTP на HTTPS, а не наоборот. Это было бы трудно увидеть, потому что nginx по умолчанию не включает протокол запроса в журнал.

...