Я настраиваю разбивку на страницы для определенной конечной точки DRF, которая работает хорошо, однако при развертывании на моем сервере, который использует HTTPS, ссылки на следующую и предыдущие страницы формируются с помощью http://
вместо https://
. Это заставляет браузер блокировать следующие/предыдущие страницы.
Я дважды проверил, что был отправлен исходный запрос, с HTTPS, а второй ответ на этот вопрос утверждает, что он должен использовать HTTPS в сформированных URL-адресах поскольку запрос пришел через HTTPS.
Первый ответ на тот же вопрос тоже не помог - я добавил строку X-Forwarded-Proto
в мою конфигурацию nginx и перезагрузился, но безрезультатно.
В документах DRF упоминается, что reverse() должен вести себя как базовый Django reverse, однако кажется довольно очевидным, что первоначальный запрос является HTTPS while возвращаемый URL-адрес - HTTP.
Вот несколько скриншотов, которые показывают начальный запрос (https://<domain>.com/api/leaderboard/
):
С ответом, содержащим next: http://<domain>.com/api/leaderboard/?page=2
):
Я понял, что это будет простая настройка, но не удалось найти что-либо после поиска как этого сайта, так и сайта DRF.
Это моя конфигурация nginx:
location / {
# proxy_pass http://127.0.0.1:9900;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
root /opt/app/client/dist;
index index.html index.htm;
}
Этот вопрос содержит довольно подробный ответ, но в конечном итоге говорит, что URL-адреса сформированы с тем же протоколом, что и запрос, что, похоже, не имеет места здесь, Нужно ли устанавливать этот Django SECURE_PROXY_SSL_HEADER? Я не был уверен, учитывая предупреждение, что это потенциально небезопасно.