Shiny: 使客户端 IP 地址在 clientData 上可用

还有 HTTP 请求标头。

http://rod.vagg.org/2011/07/wrangling-the-x-forwarded-for-header/

在这方面有任何动静吗？ @jcheng5

@coatless不，但你需要它做什么？

我有一个闪亮的应用程序，它被设置为允许学生提交作业。 该应用程序现在只能记录操作提交时的用户名和提交时间。 传递给闪亮应用程序的 IP 地址请求是因为它使我能够将用户的 IP 与提交的分配一起存储。 这将提供额外的证据来支持学术诚信违规，因为在我当前的设置下，两份提交的排名相似。

公开请求IP的另一票

又是一票。

如果您的应用程序是使用Connect或Shinyapps.io部署的，那么执行此操作的方法有点

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
  if ("HTTP_X_FORWARDED_FOR" %in% ls(req)) ui_xfwd <<- req[["HTTP_X_FORWARDED_FOR"]]
  fluidPage(
    h3("result"),
    uiOutput("result")
  )
}

server <- function(input, output, session) {
  output$result <- renderUI({
    if (!is.null(ui_xfwd)) {
      div(
        p("HTTP_X_FORWARDED_FOR header present in UI:"),
        p(ui_xfwd)
      )
    } else {
      div(
        p("HTTP_X_FORWARDED_FOR header not present; here's the REMOTE_ADDR:"),
        p(session$request[["REMOTE_ADDR"]])
      )
    }
  })
}

shinyApp(ui, server)

我不会这样做——稍后我会发布一个更强大的解决方法。

@jcheng5关于鲁棒方法的任何 eta？

抱歉耽搁了。 @bborgesr的方法的问题在于，它假设每当服务器功能运行时，紧接在前面的 UI 请求来自同一个浏览器。 这不一定是真的——完全有可能由于重叠的流量或者当用户点击后退按钮时 UI 被缓存，这些请求不是连续的。

如果您不太担心欺诈，那么更可靠的方法是将 IP 地址注入生成的 UI。 我希望我们有一个<input type="hidden">的输入绑定，但我们目前没有，所以你可以隐藏一个文本输入。

library(shiny)

ui <- function(req) {
  fluidPage(
    div(style = "display: none;",
      textInput("remote_addr", "remote_addr",
        if (!is.null(req[["HTTP_X_FORWARDED_FOR"]]))
          req[["HTTP_X_FORWARDED_FOR"]]
        else
          req[["REMOTE_ADDR"]]
      )
    )
  )
}

server <- function(input, output, session) {
  cat("The remote IP is", isolate(input$remote_addr), "\n")
}

shinyApp(ui, server)

如果您更担心欺诈，那么不幸的是，您将不得不等待适当的修复程序才能登陆我们的服务器产品。

@jcheng5是否有关于何时正确修复的预计

@coatless实际上我仔细观察了一下，这似乎应该已经与 Shiny Server Pro 一起使用了（将以下内容添加到/etc/shiny-server/shiny-server.conf ）：

whitelist_headers "x-forwarded-for";

然后您可以从服务器函数中查找session$req$HTTP_X_FORWARDED_FOR 。

这将是下一版 Shiny Server Open Source (cc @alandipert @shalutiwari) 的一个很好的候选者，但肯定不会在二月初的 rstudio::conf 之前发布另一个版本。 所以至少一两个月。 抱歉，我无法得到比这更具体的信息。

@jcheng5很棒。 一千谢谢伙计！

没关系， whitelist_headers不起作用——它运行的代码路径首先没有正确的标头。 让我看看我能不能解决这个问题。

自我说明（和@alandipert）：

• node-http-proxy 的xfwd实现并不理想； 看到这里。 它不保留现有的X-Forwarded-For标头（如果您是代理，如果上游代理受信任，您应该将 remote-addr 附加到任何现有X-Forwarded-For标头的末尾）。 理想情况下，我们不会使用它，而是自己在lib/proxy/http.js实现这些标头。 可能希望管理员告诉我们上游代理是否可信（或者更好的是，哪些 IP 应该被视为可信代理）。
• 为 websocket 实现X-Forwarded-*很简单； SockJS 允许这些标头通过。 在lib/proxy/sockjs.js ， createWebSocketClient可以接受标头作为它的第二个参数，您可以通过conn.$conn._conn.headers获取请求标头（显然我们应该添加访问器而不是读取私有字段）。

这事有进一步更新吗？ 在 Shiny 中公开请求 IP 会非常有用。

访问客户端的 IP 地址在我的项目中也非常有用。 我们有可能在即将发布的版本中看到此功能吗？

如果您的应用程序是使用Connect或Shinyapps.io部署的，那么执行此操作的方法有点

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

有没有办法从 Shiny 模块中访问请求信息（甚至以一种骇人听闻的方式）？

有没有办法从 Shiny 模块中访问请求信息（甚至以一种骇人听闻的方式）？

@jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) 建议的方法应该在模块内工作（一旦它得到完全支持）

我通过@jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-352564869) 得到了解决方案，通过将请求环境（他的代码中的req ）传递给 sub - 来自主 ui 功能的模块。

但是现在我看到的值为 127.0.0.1，即使从不同的机器访问也是如此。 这是预期的吗？

这似乎不是预期的，但有时会发生在用户身上： https :

有人知道如何使用 apache 反向代理应用此解决方案吗？

如果我在安装在我的 VM 上的 RStudio 服务器上运行这个解决方案它工作正常，但是当我将它传递给生产时，我实现了反向代理，IP 总是 127.0.0.1