Shiny: Disponibilizar o endereço IP do cliente em clientData

Também cabeçalhos de solicitação HTTP.

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

Algum movimento aconteceu sobre isso? @ jcheng5

@coatless Não, mas para que você precisava?

Tenho um aplicativo brilhante configurado para permitir que os alunos enviem trabalhos de casa. No momento, o aplicativo só é capaz de registrar nomes de usuário e tempos de envio no envio da ação. A solicitação de endereços IP que estão sendo passados ​​para o aplicativo brilhante é porque me permitiria armazenar o IP do usuário junto com a atribuição enviada. Isso forneceria evidências adicionais para apoiar uma violação de integridade acadêmica devido a duas submissões sendo classificadas de forma semelhante em minha configuração atual.

Outro voto para expor IP de solicitação

Mais uma votação.

Se o seu aplicativo for implantado usando Connect ou brilhanteapps.io , há uma maneira um pouco hacky de fazer isso. Estamos trabalhando para tornar isso menos hacky, tornando-o acessível do lado do servidor (e de todo no servidor brilhante), portanto, esta não é a palavra final sobre o assunto. Eu só queria compartilhar o que funciona hoje, se for útil para algum de vocês:

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)

Eu não faria isso dessa forma - postarei uma solução alternativa mais robusta em breve.

@ jcheng5 algum eta no método robusto?

Desculpe pelo atraso. O problema com o método de @bborgesr é que ele assume que, sempre que a função do servidor é executada, a solicitação de IU imediatamente anterior era do mesmo navegador. Isso não é necessariamente verdade - é inteiramente possível que essas solicitações não sejam consecutivas devido à sobreposição de tráfego ou talvez a IU sendo armazenada em cache quando o usuário pressiona o botão Voltar.

Se você não estiver muito preocupado com a fraude, uma maneira mais confiável de fazer isso é injetar o endereço IP na IU gerada. Eu gostaria que tivéssemos uma ligação de entrada para <input type="hidden"> mas não temos isso atualmente, então você pode ocultar uma entrada de texto em seu lugar.

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)

Se você está mais preocupado com a fraude, infelizmente terá que esperar pela solução adequada para chegar aos nossos produtos de servidor.

@ jcheng5 existe uma

@coatless Na verdade, dei uma olhada mais de perto e parece que já deve funcionar com o Shiny Server Pro (adicionando o seguinte a /etc/shiny-server/shiny-server.conf ):

whitelist_headers "x-forwarded-for";

Então você pode procurar session$req$HTTP_X_FORWARDED_FOR na função do servidor.

Este seria um bom candidato para a próxima versão do Shiny Server Open Source (cc @alandipert @shalutiwari), mas certamente não haverá outro lançamento antes de rstudio :: conf no início de fevereiro. Então, pelo menos alguns meses. Desculpe, não posso ser mais específico do que isso.

@ jcheng5 excelente. Mil obrigado cara!

Não importa, o whitelist_headers não funciona - o codepath no qual ele opera não tem os cabeçalhos corretos em primeiro lugar. Deixe-me ver se consigo descobrir isso.

Notas para mim mesmo (e @alandipert):

• A implementação xfwd para node-http-proxy não é ideal; veja aqui . Ele não preserva os cabeçalhos X-Forwarded-For (se você for um proxy, deve-se anexar o remote-addr ao final de qualquer cabeçalho X-Forwarded-For se o proxy upstream for confiável ) Idealmente, não usaríamos isso, mas, em vez disso, implementaríamos nós mesmos esses cabeçalhos em lib/proxy/http.js . Provavelmente, gostaria que o administrador nos dissesse se o proxy upstream é confiável (ou melhor ainda, quais IPs devem ser considerados proxies confiáveis).
• Implementar X-Forwarded-* para websocket é simples; O SockJS permite a passagem desses cabeçalhos. Em lib/proxy/sockjs.js , createWebSocketClient pode aceitar cabeçalhos como seu segundo argumento, e você pode obter os cabeçalhos da solicitação por meio de conn.$conn._conn.headers (obviamente, devemos adicionar acessadores em vez de ler campos privados).

alguma atualização disso? Expor o IP de solicitação dentro do brilhante seria bastante útil.

Ter acesso ao endereço IP do cliente também seria muito útil em meus projetos. Alguma chance de vermos esse recurso em um próximo lançamento?

Se o seu aplicativo for implantado usando Connect ou brilhanteapps.io , há uma maneira um pouco hacky de fazer isso. Estamos trabalhando para tornar isso menos hacky, tornando-o acessível do lado do servidor (e de todo no servidor brilhante), portanto, esta não é a palavra final sobre o assunto. Eu só queria compartilhar o que funciona hoje, se for útil para algum de vocês:

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

Existe uma maneira de acessar as informações da solicitação (mesmo de forma hacky) de dentro de um Módulo Shiny?

Existe uma maneira de acessar as informações da solicitação (mesmo de forma hacky) de dentro de um Módulo Shiny?

A abordagem sugerida por @ jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) deve funcionar a partir de um módulo (uma vez que seja totalmente compatível)

Eu consegui a solução por @ jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-352564869) para funcionar passando o ambiente de solicitação ( req em seu código) para o sub -módulo da função principal da interface do usuário.

Mas agora estou vendo um valor de 127.0.0.1, mesmo quando acessado de uma máquina diferente. Isso é esperado?

Parece que NÃO é esperado, mas às vezes acontece com os usuários: https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Alguém sabe como aplicar esta solução usando um proxy reverso apache?

Se eu executar esta solução no servidor RStudio instalado na minha VM, ela funciona bem, mas quando eu passo para produção, onde tenho um proxy reverso implementado, o IP é sempre 127.0.0.1