R 是否可以确定登录到nginx反向代理的用户

我已经成功地为我的闪亮服务器实现了一个nginx反向代理，以便进行SSL和用户身份验证。然而，仍然有一个差距，我无法找出。我的闪亮应用程序是否有办法确定哪个用户实际登录

这里是my/etc/nginx/sites available/default

server {
listen 80;
return 301 https://$host$request_uri;
}

server {

listen 443;
server_name myserver.com;

ssl_certificate           /etc/nginx/cert.crt;
ssl_certificate_key       /etc/nginx/cert.key;

ssl on;
ssl_session_cache  builtin:1000  shared:SSL:10m;
ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

access_log            /var/log/nginx/shiny.log;

location / {

  proxy_set_header        Host $host;
  proxy_set_header        X-Real-IP $remote_addr;
  proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header        X-Forwarded-Proto $scheme;

  # Fix the “It appears that your reverse proxy set up is broken" error.
  proxy_pass          http://localhost:3838;
  proxy_read_timeout  90;

  proxy_redirect      http://localhost:3838 https://myserver.com;
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
  proxy_set_header Authorization $http_authorization;
  proxy_pass_header  Authorization;
}
  }

对于位置的最后两行，我希望有一个带有用户名的标题。我找到了那个小费。我发现它允许我查看标题信息，但我看到的标题中没有一个是我的用户名

编辑：

有了Bert Neef的引证，我明白了为什么上面的说法不起作用。但是，服务器确实可以访问HTTP_SEC_WEBSOCKET_密钥头，该密钥头在会话中是唯一的。看起来，如果我们可以让Nginx记录该值，那么服务器就可以查看该代码，将头与实际用户匹配。话虽如此，我不知道这是否可行，也不知道如何让Nginx记录该值。

基于此，这只是一个闪亮的服务器专业功能，您需要使用whitelist_headers指令来获取这些头：

4.9代理标头 通常，发送到Shiny Server的HTTP头不会转发到底层Shiny应用程序。然而，闪亮的 Server Professional能够将指定的头转发到 使用白名单标题的闪亮应用程序， 可以全局设置，也可以为特定服务器或位置设置

更新：刚刚在一个非pro Shining服务器安装中测试了白名单标题选项，我无法显示自定义标题。通过使用netcat向我显示传入数据（nc-L8080和nginx.conf文件中对proxy_pass的快速更改），我确实验证了报头是由nginx发送的

---

更新2：无法让NGINX记录HTTP_SEC_WEBSOCKET_密钥头（授权头在日志规范中指定后记录），并且我在NGINX和服务器之间的通信中看不到它，我认为这要么归结为获得闪亮的Server Professional，要么修改闪亮的源代码以将授权头传递给应用程序。

如果这看起来很苛刻，很抱歉，但我不会因为“你必须购买专业版”而奖励奖金。Shining server至少接受一些标题，甚至您引用的代码段也用“通常”限定，所以一定有办法。这完全取决于您。我希望其他人能提供方法。似乎这样做的方法是使用HTTP_SEC_WEBSOCKET_密钥头。它对shiny是可用的，并且对于每个登录似乎都是唯一的，因此如果我们可以让nginx日志记录每个用户对该头的内容，那么shiny可以查看该日志并将websocket_密钥头与实际用户匹配。我不知道这是否可行，也不知道如何在nginx端进行日志记录。我尝试通过nginx将日志记录到它的access.log，我可以简单地记录身份验证头，它是base64编码的，但从中获取用户名很容易，HTTP_SEC_WEBSOCKET_密钥似乎不存在，当我告诉nginx记录日志时，日志中没有显示任何内容，而当我尝试netcat技巧时，我也没有看到它。也许它是shiny服务器的内部，我目前没有安装tcpdump。我会看看我是否能通过抓包获得更多信息。请记住，这不是一种非常安全的用户处理方法，即使它可以工作。这样做不会使通过NginX身份验证变得更容易，我也不担心任何用户相互欺骗。