时间戳

首页 > 解决方案 > Nginx 重定向到 Phoenix 丢失授权标头

nginx - Nginx 重定向到 Phoenix 丢失授权标头

问题描述

我有一个使用 Cloud Run 部署的 Phoenix Framework 应用程序，并且有多个客户端使用它。

由于 Cloud Run 后台任务限制，我想将部署移动到 Computer Engine，但我不想强制客户端更新他们的应用程序（即后端 url）。

所以我虽然可以在 Cloud Run 中部署一个 Ngnix 实例，将所有内容重定向到 Compute Engine。

问题是我使用了一个没有到达 Phoenix 连接的授权请求标头。我已经用不同的服务器（Python simpleserver）尝试过它，它正确地接收了每个标头。

所以，问题是。如果它们来自重定向，Phoenix Framework 是否会过滤掉一些请求标头？

标题是： {"authorization", "Bearer XXX"}

ngixn.conf 很简单：

server {
    listen 80;
    return 301 http://0.0.0.0:4000$request_uri;
}

检查conn.req_headers：

$curl -L --location --request GET 'http://localhost:80' \
--header 'Content-Type: application/json' --header 'other: whatever'  \
--header 'Authorization: Bearer XXXX' \
--data-raw ''`

检查给出：

[
  {"accept", "*/*"},
  {"content-type", "application/json"},
  {"host", "0.0.0.0:4000"},
  {"other", "whatever"},
  {"user-agent", "curl/7.54.0"}
]

如果卷曲直接到 Phoenix 服务器应用程序：

curl -L --location --request GET 'http://localhost:4000' \
--header 'Content-Type: application/json' --header 'other: whatever'  \
--header 'Authorization: Bearer XXXX' \
--data-raw ''`

我们有：

[
  {"accept", "*/*"},
  {"authorization", "Bearer XXXX"},
  {"content-length", "0"},
  {"content-type", "application/json"},
  {"host", "localhost:4000"},
  {"other", "whatever"},
  {"user-agent", "curl/7.54.0"}
]

已编辑

Python 服务器也不接收授权标头。

直接请求服务器：

127.0.0.1 - - [03/Nov/2020 07:22:30] "GET / HTTP/1.1" 200 -
Host: localhost:4000
User-Agent: curl/7.54.0
Accept: */*
Content-Type: application/json
other: whatever
Authorization: Bearer XXXX
Content-Length: 0

通过 Nginx 重定向的请求：

127.0.0.1 - - [03/Nov/2020 07:22:41] "GET / HTTP/1.1" 200 -
Host: 0.0.0.0:4000
User-Agent: curl/7.54.0
Accept: */*
Content-Type: application/json
other: whatever

所以我猜 Nginx 正在“捕获”身份验证标头并且不会让它通过

标签： nginxredirectelixirphoenix-framework

解决方案

这是 curl 的一个特性。如果请求被重定向到不同的主机名，则将Authorization在第二个请求中删除任何标头，以免将凭据泄漏到不相关的服务器。（您正在向 发出请求localhost:80，但重定向位置是0.0.0.0:4000，因此这被视为不同的主机名。）

您可以Authorization通过使用--location-trusted选项而不是-L.

（尽管您在 curl 7.54.0 中看到这一点很奇怪 - 根据此安全公告，curl 7.54.0 应该按照您的预期运行，并且只有 7.58.0 及更高版本具有此保护功能。）

推荐阅读