Shiny: Hacer que la dirección IP del cliente esté disponible en clientData

También encabezados de solicitud HTTP.

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

¿Ha ocurrido algún movimiento sobre esto? @ jcheng5

@coatless No, pero ¿para qué lo necesitabas?

Tengo una aplicación brillante que está configurada para permitir que los estudiantes envíen tareas. La aplicación en este momento solo puede registrar nombres de usuario y tiempos de envío en el envío de acciones. La solicitud de direcciones IP que se pasan a la aplicación brillante se debe a que me permitiría almacenar la IP del usuario junto con la asignación enviada. Esto proporcionaría evidencia adicional para respaldar una violación de la integridad académica debido a que dos presentaciones se clasifican de manera similar en mi configuración actual.

Otro voto para exponer la propiedad intelectual de la solicitud

Otro voto más.

Si su aplicación se implementa usando Connect o shinyapps.io , hay una forma un tanto hacker de hacer esto. Estamos trabajando para hacer que esto sea menos pirateado haciéndolo accesible desde el lado del servidor (y en absoluto en el servidor brillante), por lo que esta no es la última palabra sobre el tema. Solo quería compartir lo que funciona hoy en caso de que sea útil para alguno de ustedes:

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)

No lo haría de esta manera, publicaré una solución alternativa más sólida en un momento.

@ jcheng5 alguna eta sobre el método robusto?

Pido disculpas por la demora. El problema con el método de @bborgesr es que asume que cada vez que se ejecuta la función del servidor, la solicitud de IU inmediatamente anterior proviene del mismo navegador. Eso no es necesariamente cierto: es muy posible que esas solicitudes no sean consecutivas debido al tráfico superpuesto o tal vez la interfaz de usuario se haya almacenado en caché cuando el usuario presiona el botón Atrás.

Si no está demasiado preocupado por el fraude, una forma más confiable de hacerlo es inyectar la dirección IP en la interfaz de usuario generada. Ojalá tuviéramos un enlace de entrada para <input type="hidden"> pero actualmente no lo tenemos, por lo que puedes ocultar una entrada de texto.

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)

Si está más preocupado por el fraude, lamentablemente tendrá que esperar a que llegue la solución adecuada a nuestros productos de servidor.

@ jcheng5 ¿hay una ETA sobre cuándo aterrizará la solución adecuada? (¿1 mes, 6 meses, año?)

@coatless En realidad, eché un vistazo más de cerca y parece que ya debería funcionar con Shiny Server Pro (agregando lo siguiente a /etc/shiny-server/shiny-server.conf ):

whitelist_headers "x-forwarded-for";

Entonces podría buscar session$req$HTTP_X_FORWARDED_FOR dentro de la función del servidor.

Este sería un buen candidato para la próxima versión de Shiny Server Open Source (cc @alandipert @shalutiwari) pero ciertamente no habrá otro lanzamiento antes de rstudio :: conf a principios de febrero. Así que al menos un par de meses. Lo siento, no puedo ser más específico que eso.

@ jcheng5 excelente. ¡Mil gracias amigo!

No importa, el whitelist_headers no funciona: la ruta de código en la que opera no tiene los encabezados correctos en primer lugar. Déjame ver si puedo resolver esto.

Notas para mí mismo (y @alandipert):

• La implementación xfwd para node-http-proxy no es ideal; ver aquí . No conserva los encabezados X-Forwarded-For (si es un proxy, se supone que debe agregar la dirección remota al final de cualquier encabezado X-Forwarded-For si el proxy ascendente es de confianza ). Idealmente, no usaríamos esto, sino que implementaríamos estos encabezados nosotros mismos en lib/proxy/http.js . Probablemente querrá que el administrador nos diga si el proxy ascendente es confiable (o mejor aún, qué IP deben considerarse proxies confiables).
• Implementar X-Forwarded-* para websocket es sencillo; SockJS permite que estos encabezados pasen. En lib/proxy/sockjs.js , createWebSocketClient puede aceptar encabezados como su segundo argumento, y puede obtener los encabezados de solicitud a través de conn.$conn._conn.headers (obviamente, deberíamos agregar descriptores de acceso en lugar de leer campos privados).

¿Algún avance en esto? Exponer la IP de la solicitud dentro de shiny sería bastante útil.

Tener acceso a la dirección IP del cliente también sería muy útil en mis proyectos. ¿Hay alguna posibilidad de que veamos esta función en una próxima versión?

Si su aplicación se implementa usando Connect o shinyapps.io , hay una forma un tanto hacker de hacer esto. Estamos trabajando para hacer que esto sea menos pirateado haciéndolo accesible desde el lado del servidor (y en absoluto en el servidor brillante), por lo que esta no es la última palabra sobre el tema. Solo quería compartir lo que funciona hoy en caso de que sea útil para alguno de ustedes:

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

¿Hay alguna forma de acceder a la información de la solicitud (incluso de forma pirata) desde dentro de un módulo brillante?

¿Hay alguna forma de acceder a la información de la solicitud (incluso de forma pirata) desde dentro de un módulo brillante?

El enfoque sugerido por @ jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) debería funcionar desde dentro de un módulo (una vez que sea totalmente compatible)

Obtuve la solución de req en su código) a través del sub -módulo de la función de interfaz de usuario principal.

Pero ahora veo un valor de 127.0.0.1, incluso cuando se accede desde una máquina diferente. ¿Es esto esperado?

Parece que NO se espera, pero a veces les pasa a los usuarios: https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

¿Alguien sabe cómo aplicar esta solución usando un proxy inverso de apache?

Si ejecuto esta solución en el servidor RStudio instalado en mi VM, funciona bien, pero cuando la paso a producción, donde tengo implementado un proxy inverso, la IP es siempre 127.0.0.1