Shiny: Rendre l'adresse IP du client disponible sur clientData

Aussi les en-têtes de requête HTTP.

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

Y a-t-il eu un mouvement à ce sujet ? @jcheng5

@coatless Non, mais pour quoi en aviez-vous besoin ?

J'ai une application brillante qui est configurée pour permettre aux étudiants de soumettre leurs devoirs. L'application ne peut actuellement enregistrer les noms d'utilisateur et les heures de soumission que lors de la soumission de l'action. La demande d'adresses IP transmise à l'application brillante est due au fait que cela me permettrait de stocker l'adresse IP de l'utilisateur avec l'affectation soumise. Cela fournirait des preuves supplémentaires pour étayer une violation de l'intégrité académique en raison de deux soumissions classées de la même manière dans ma configuration actuelle.

Un autre vote pour exposer la demande IP

Encore un vote.

Si votre application est déployée à l'aide de Connect ou de shinyapps.io , il existe un moyen assez compliqué de le faire. Nous travaillons à rendre cela moins piraté en le rendant accessible côté serveur (et pas du tout dans un serveur brillant), donc ce n'est pas le dernier mot sur le sujet. Je voulais juste partager ce qui fonctionne aujourd'hui si c'est utile pour l'un d'entre vous :

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)

Je ne le ferais pas de cette façon - je publierai une solution de contournement plus robuste dans un instant.

@jcheng5 un eta sur la méthode robuste ?

Désolé pour le retard. Le problème avec la méthode de @bborgesr est qu'elle suppose que chaque fois que la fonction serveur s'exécute, la demande d'interface utilisateur immédiatement précédente provenait du même navigateur. Ce n'est pas nécessairement vrai - il est tout à fait possible que ces demandes ne soient pas consécutives en raison du trafic qui se chevauche ou peut-être que l'interface utilisateur est mise en cache lorsque l'utilisateur appuie sur le bouton de retour.

Si vous n'êtes pas trop préoccupé par la fraude, un moyen plus fiable de le faire consiste à injecter l'adresse IP dans l'interface utilisateur générée. Je souhaite que nous ayons une liaison d'entrée pour <input type="hidden"> mais nous ne l'avons pas actuellement, vous pouvez donc masquer une entrée de texte à la place.

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 vous êtes plus préoccupé par la fraude, vous devrez malheureusement attendre que le correctif approprié atterrisse dans nos produits de serveur.

@jcheng5 y a-t-il un ETA sur le moment où le correctif approprié atterrira? (1 mois, 6 mois, année ?)

@coatless En fait, j'ai regardé de plus près et il semble que cela devrait déjà fonctionner avec Shiny Server Pro (en ajoutant ce qui suit à /etc/shiny-server/shiny-server.conf ):

whitelist_headers "x-forwarded-for";

Ensuite, vous pouvez rechercher session$req$HTTP_X_FORWARDED_FOR dans la fonction serveur.

Ce serait un bon candidat pour la prochaine version de Shiny Server Open Source (cc @alandipert @shalutiwari) mais il n'y aura certainement pas d'autre version avant rstudio::conf début février. Donc au moins quelques mois. Désolé, je ne peux pas être plus précis que cela.

@jcheng5 excellent. Mille mercis mon pote !

Peu importe, le whitelist_headers ne fonctionne pas - le chemin de code sur lequel il opère n'a pas les bons en-têtes en premier lieu. Laissez-moi voir si je peux comprendre cela.

Notes à moi-même (et @alandipert) :

• L'implémentation xfwd pour node-http-proxy n'est pas idéale ; voir ici . Il ne conserve pas les en-têtes X-Forwarded-For existants (si vous êtes un proxy, vous êtes censé ajouter le remote-addr à la fin de tout en-tête X-Forwarded-For existant si le proxy en amont est de confiance ). Idéalement, nous n'utiliserions pas cela mais implémenterions ces en-têtes nous-mêmes dans lib/proxy/http.js . Voudrait probablement que l'administrateur nous dise si le proxy en amont est de confiance (ou mieux encore, quelles IP doivent être considérées comme des proxys de confiance).
• L'implémentation de X-Forwarded-* pour websocket est simple ; SockJS autorise le passage de ces en-têtes. Dans lib/proxy/sockjs.js , createWebSocketClient peut accepter les en-têtes comme deuxième argument, et vous pouvez obtenir les en-têtes de requête via conn.$conn._conn.headers (évidemment, nous devrions ajouter des accesseurs au lieu de lire des champs privés).

Une mise à jour pour ceci? Exposer l'IP de la requête à l'intérieur de shiny serait très utile.

Avoir accès à l'adresse IP du client serait également très utile dans mes projets. Y a-t-il une chance que nous voyions cette fonctionnalité dans une prochaine version ?

Si votre application est déployée à l'aide de Connect ou de shinyapps.io , il existe un moyen assez compliqué de le faire. Nous travaillons à rendre cela moins piraté en le rendant accessible côté serveur (et pas du tout dans un serveur brillant), donc ce n'est pas le dernier mot sur le sujet. Je voulais juste partager ce qui fonctionne aujourd'hui si c'est utile pour l'un d'entre vous :

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

Existe-t-il un moyen d'accéder aux informations de la demande (même de manière piratée) à partir d'un module Shiny ?

Existe-t-il un moyen d'accéder aux informations de la demande (même de manière piratée) à partir d'un module Shiny ?

L'approche suggérée par @jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) devrait fonctionner à partir d'un module (une fois qu'il est entièrement pris en charge)

J'ai obtenu la solution de @jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-352564869) pour fonctionner en passant l'environnement de requête ( req dans son code) via le sous -module de la fonction principale de l'interface utilisateur.

Mais maintenant, je vois une valeur de 127.0.0.1, même en cas d'accès à partir d'une autre machine. Est-ce prévu ?

Il semble que ce ne soit PAS prévu, mais cela arrive parfois aux utilisateurs : https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Est-ce que quelqu'un sait comment appliquer cette solution à l'aide d'un proxy inverse Apache ?

Si j'exécute cette solution sur le serveur RStudio installé sur ma VM, cela fonctionne bien, mais lorsque je la passe en production, où j'ai implémenté un proxy inverse, l'IP est toujours 127.0.0.1