Shiny: clientDataでクライアントIPアドレスを利用できるようにする

また、HTTPリクエストヘッダー。

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

これで何か動きがありましたか？ @ jcheng5

@coatlessいいえ、でも何のために必要だったのですか？

学生が宿題を提出できるように設定された光沢のあるアプリケーションがあります。 現在、アプリはアクション送信時にユーザー名と送信時間を記録することしかできません。 光沢のあるアプリに渡されるIPアドレスのリクエストは、送信された割り当てとともにユーザーのIPを保存できるようにするためです。 これは、私の現在の設定で2つの提出物が同様にランク付けされているため、学術的完全性違反を裏付ける追加の証拠を提供します。

リクエスト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ロバストな方法に関するエタはありますか？

遅れて申し訳ありません。 @bborgesrによるメソッドの問題は、サーバー関数が実行されるたびに、直前のUI要求が同じブラウザーからのものであると想定することです。 これは必ずしも真実ではありません。トラフィックが重複しているため、またはユーザーが戻るボタンを押したときにUIがキャッシュされているために、これらのリクエストが連続していない可能性があります。

詐欺についてあまり心配していない場合、これを行うためのより信頼性の高い方法は、生成されたUIにIPアドレスを挿入することです。 <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適切な修正がいつ着陸するかについてのETAはありますか？ （1ヶ月、6ヶ月、年？）

@coatless実際に詳しく調べたところ、Shiny Server Proですでに機能しているようです（ /etc/shiny-server/shiny-server.conf以下を追加）：

whitelist_headers "x-forwarded-for";

次に、サーバー関数内からsession$req$HTTP_X_FORWARDED_FORを探すことができます。

これはShinyServerオープンソースの次のバージョン（cc

@ jcheng5すばらしい。 千の感謝の仲間！

whitelist_headersは機能しません。動作するコードパスには、そもそも適切なヘッダーがありません。 私がこれを理解できるかどうか見てみましょう。

自己（および@alandipert）へのメモ：

• node-http-proxyのxfwd実装は理想的ではありません。 ここを参照してください。 既存のX-Forwarded-Forヘッダーは保持されません（プロキシの場合、アップストリームプロキシが信頼されている場合は、既存のX-Forwarded-Forヘッダーの末尾にremote-addrを追加する必要があります）。 理想的には、これを使用せず、代わりにこれらのヘッダーをlib/proxy/http.js実装します。 おそらく、管理者に、アップストリームプロキシが信頼されているかどうか（または、さらに良いことに、どのIPを信頼されたプロキシと見なす必要があるか）を教えてもらいたいでしょう。
• WebSocketにX-Forwarded-*を実装するのは簡単です。 SockJSは、これらのヘッダーを通過させます。 lib/proxy/sockjs.jsでは、 createWebSocketClientは2番目の引数としてヘッダーを受け入れることができ、 conn.$conn._conn.headersを介してリクエストヘッダーを取得できます（明らかに、プライベートフィールドを読み取る代わりにアクセサーを追加する必要があります）。

これに関する更新はありますか？ 光沢のある内部にリクエストIPを公開すると非常に便利です。

クライアントのIPアドレスにアクセスできることは、私のプロジェクトでも非常に役立ちます。 今後のリリースでこの機能が表示される可能性はありますか？

アプリがConnectまたはshinyapps.ioを使用してデプロイされている場合、これを行うには少しハッキーな方法があります。 サーバー側から（そして光沢のあるサーバーで）アクセスできるようにすることで、これをよりハッキーにしないように取り組んでいるので、これはトピックの最後の言葉ではありません。 それがあなたの誰かに役立つ場合、私は今日何がうまくいくかを共有したかっただけです：

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

シャイニーモジュール内からリクエスト情報に（ハッキーな方法でも）アクセスする方法はありますか？

シャイニーモジュール内からリクエスト情報に（ハッキーな方法でも）アクセスする方法はありますか？

@ jcheng5 （https://github.com/rstudio/shiny/issues/141#issuecomment-351857670）によって提案されたアプローチは、モジュール内から機能するはずです（完全にサポートされた後）

@ jcheng5 （https://github.com/rstudio/shiny/issues/141#issuecomment-352564869）によって、リクエスト環境（彼のコードではreq ）をサブに渡すことで機能するソリューションを入手しました-メインのUI関数からのモジュール。

しかし、別のマシンからアクセスした場合でも、127.0.0.1の値が表示されます。 これは予想されますか？

予期されていないようですが、ユーザーに発生することがあります： https ：

誰かがApacheリバースプロキシを使用してこのソリューションを適用する方法を知っていますか？

VMにインストールされているRStudioサーバーでこのソリューションを実行すると正常に機能しますが、リバースプロキシが実装されている本番環境に渡すと、IPは常に127.0.0.1になります。