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

时间:2020-11-01 17:26:20

标签: nginx redirect elixir phoenix-framework

我有一个与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正在“捕获”身份验证标头,并且不允许它通过

1 个答案:

答案 0 :(得分:2)

这是卷曲功能。如果将请求重定向到其他主机名,则将在第二个请求中删除任何 List<Devices> devicesdata = new List<Devices>() { //add Devices. }; _dbcontext.Devices.AddRange(devicesdata); _dbcontext.SaveChanges(); 头,以免将凭据泄漏给不相关的服务器。 (您正在向Authorization发出请求,但重定向位置为localhost:80,因此它算作另一个主机名。)

通过使用0.0.0.0:4000而不是Authorization选项,您可以卷曲来转发--location-trusted标头。

(虽然奇怪的是您在curl 7.54.0上看到了这一点-根据this security advisory,curl 7.54.0的行为应与您预期的一样,只有7.58.0和更高版本具有此保护功能)