Shiny: Client-IP-Adresse in clientData verfügbar machen

Auch HTTP-Request-Header.

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

Hat sich diesbezüglich etwas bewegt? @jcheng5

@coatless Nein, aber wofür brauchten Sie es?

Ich habe eine glänzende Anwendung, die so eingerichtet ist, dass Schüler ihre Hausaufgaben einreichen können. Die App kann derzeit nur Benutzernamen und Übermittlungszeiten beim Senden von Aktionen aufzeichnen. Die Anfrage nach IP-Adressen, die an die Shiny-App weitergegeben werden, besteht darin, dass ich die IP des Benutzers zusammen mit der übermittelten Aufgabe speichern könnte. Dies würde zusätzliche Beweise für eine Verletzung der akademischen Integrität liefern, da zwei Einreichungen in meinem aktuellen Setup ähnlich eingestuft werden.

Eine weitere Stimme für die Offenlegung des Antrags IP

Noch eine Stimme.

Wenn Ihre App mit Connect oder Shinyapps.io bereitgestellt wird , gibt es eine etwas hackige Möglichkeit, dies zu tun. Wir arbeiten daran, dies weniger hackig zu machen, indem wir es von der Serverseite (und überhaupt vom Shiny-Server) zugänglich machen, also ist dies nicht das letzte Wort zu diesem Thema. Ich wollte nur teilen, was heute funktioniert, falls es für jeden von Ihnen nützlich ist:

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)

Ich würde es nicht so machen - ich werde in Kürze eine robustere Problemumgehung veröffentlichen.

@jcheng5 irgendwelche eta zur robusten Methode?

Entschuldigung für die Verspätung. Das Problem bei der Methode von @bborgesr besteht darin, dass sie bei

Wenn Sie sich keine Sorgen über Betrug machen, können Sie dies zuverlässiger tun, indem Sie die IP-Adresse in die generierte Benutzeroberfläche einfügen. Ich wünschte, wir hätten eine Eingabebindung für <input type="hidden"> aber die haben wir derzeit nicht, sodass Sie stattdessen eine Texteingabe ausblenden können.

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)

Wenn Sie sich mehr Sorgen um Betrug machen, müssen Sie leider warten, bis die richtige Lösung in unseren Serverprodukten landet.

@jcheng5 gibt es eine ETA, wann die richtige Lösung landen wird? (1 Monat, 6 Monate, Jahr?)

@coatless Eigentlich habe ich genauer /etc/shiny-server/shiny-server.conf ):

whitelist_headers "x-forwarded-for";

Dann könnten Sie in der Serverfunktion nach session$req$HTTP_X_FORWARDED_FOR suchen.

Dies wäre ein guter Kandidat für die nächste Version von Shiny Server Open Source (cc @alandipert @shalutiwari), aber vor rstudio::conf Anfang Februar wird es sicherlich keine weitere Veröffentlichung geben. Also mindestens ein paar Monate. Tut mir leid, genaueres kann ich nicht sagen.

@jcheng5 ausgezeichnet. Tausend Dank Kumpel!

Macht nichts, die whitelist_headers funktionieren nicht - der Codepfad, auf dem sie operiert, hat von vornherein nicht die richtigen Header. Mal sehen, ob ich das herausfinden kann.

Notizen an mich selbst (und @alandipert):

• Die Implementierung von xfwd für den Knoten-http-proxy ist nicht ideal; siehe hier . Es behält vorhandene X-Forwarded-For Header nicht bei (wenn Sie ein Proxy sind, sollten Sie die remote-addr an das Ende eines vorhandenen X-Forwarded-For Headers anhängen, wenn der Upstream-Proxy vertrauenswürdig ist ). Idealerweise würden wir dies nicht verwenden, sondern diese Header stattdessen selbst in lib/proxy/http.js implementieren. Wahrscheinlich möchte der Administrator uns mitteilen, ob der Upstream-Proxy vertrauenswürdig ist (oder besser noch, welche IPs als vertrauenswürdige Proxys gelten sollten).
• Die Implementierung von X-Forwarded-* für Websocket ist unkompliziert; SockJS lässt diese Header durch. In lib/proxy/sockjs.js kann createWebSocketClient Header als zweites Argument akzeptieren, und Sie können über conn.$conn._conn.headers auf die Anforderungsheader zugreifen (offensichtlich sollten wir Accessoren hinzufügen, anstatt private Felder zu lesen).

Gibt es hierzu Neuigkeiten? Das Offenlegen der Anfrage-IP in Shiny wäre sehr nützlich.

Der Zugriff auf die IP-Adresse des Kunden wäre auch in meinen Projekten sehr nützlich. Gibt es eine Chance, dass wir diese Funktion in einer kommenden Version sehen werden?

Wenn Ihre App mit Connect oder Shinyapps.io bereitgestellt wird , gibt es eine etwas hackige Möglichkeit, dies zu tun. Wir arbeiten daran, dies weniger hackig zu machen, indem wir es von der Serverseite (und überhaupt vom Shiny-Server) zugänglich machen, also ist dies nicht das letzte Wort zu diesem Thema. Ich wollte nur teilen, was heute funktioniert, falls es für jeden von Ihnen nützlich ist:

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

Gibt es eine Möglichkeit, von einem Shiny-Modul aus auf die Anforderungsinformationen zuzugreifen (auch auf hackige Weise)?

Gibt es eine Möglichkeit, von einem Shiny-Modul aus auf die Anforderungsinformationen zuzugreifen (auch auf hackige Weise)?

Der von @jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) vorgeschlagene Ansatz sollte innerhalb eines Moduls funktionieren (sobald es vollständig unterstützt wird).

Ich habe die Lösung von @jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-352564869) erhalten, um zu funktionieren, indem ich die Anforderungsumgebung ( req in seinem Code) an das Sub durchreiche -Modul von der Haupt-UI-Funktion.

Aber jetzt sehe ich einen Wert von 127.0.0.1, auch wenn von einem anderen Computer aus darauf zugegriffen wird. Ist dies zu erwarten?

Es scheint, dass es NICHT erwartet wird, aber manchmal passiert es Benutzern: https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Weiß jemand, wie man diese Lösung mit einem Apache-Reverse-Proxy anwendet?

Wenn ich diese Lösung auf dem auf meiner VM installierten RStudio-Server ausführe, funktioniert sie einwandfrei, aber wenn ich sie an die Produktion übergebe, wo ich einen Reverse-Proxy implementiert habe, ist die IP immer 127.0.0.1