Shiny: clientData에서 클라이언트 IP 주소를 사용할 수 있도록 설정

또한 HTTP 요청 헤더.

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

이에 대한 움직임이 있었습니까? @jcheng5

@coatless 아니요, 근데 그게 왜 필요했어요?

학생들이 숙제를 제출할 수 있도록 설정한 반짝이는 응용 프로그램이 있습니다. 현재 앱은 작업 제출 시 사용자 이름과 제출 시간만 기록할 수 있습니다. 빛나는 앱으로 전달되는 IP 주소에 대한 요청은 제출된 할당과 함께 사용자의 IP를 저장할 수 있기 때문입니다. 이것은 나의 현재 설정에서 두 개의 제출물이 유사하게 순위가 매겨졌기 때문에 학문적 청렴성 위반을 뒷받침하는 추가 증거를 제공할 것입니다.

요청 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 적절한 수정 사항이 언제 착륙할

@coatless 실제로 자세히 살펴보니 Shiny Server Pro에서 이미 작동해야 하는 것 같습니다( /etc/shiny-server/shiny-server.conf 다음 추가).

whitelist_headers "x-forwarded-for";

그런 다음 서버 기능 내에서 session$req$HTTP_X_FORWARDED_FOR 를 찾을 수 있습니다.

이것은 Shiny Server Open Source(cc @alandipert @shalutiwari)의 다음 버전에 대한 좋은 후보가 될 것이지만 확실히 2월 초에 rstudio::conf 이전에 또 다른 릴리스는 없을 것입니다. 그래서 적어도 몇 달. 이보다 더 구체적으로 말씀드릴 수 없어 죄송합니다.

@jcheng5 훌륭합니다. 천만 감사합니다!

신경쓰지 마세요. whitelist_headers 는 작동하지 않습니다. 작동하는 코드 경로에는 처음부터 올바른 헤더가 없습니다. 내가 이것을 알아낼 수 있는지 보자.

본인(및 @alandiper)에 대한 참고 사항:

• 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 는 헤더를 두 번째 인수로 허용할 수 있으며 conn.$conn._conn.headers 를 통해 요청 헤더를 가져올 수 있습니다(분명히 개인 필드를 읽는 대신 접근자를 추가해야 함).

이에 대한 업데이트가 있습니까? 샤이니 내부의 요청 IP를 노출하는 것은 매우 유용할 것입니다.

클라이언트의 IP 주소에 액세스하는 것은 내 프로젝트에서도 매우 유용할 것입니다. 다음 릴리스에서 이 기능을 볼 수 있는 기회가 있습니까?

앱이 Connect 또는 Shinyapps.io 를 사용하여 배포된 경우 이를 수행하는 약간의

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

Shiny Module 내에서 요청 정보에 접근할 수 있는 방법이 있습니까?

Shiny Module 내에서 요청 정보에 접근할 수 있는 방법이 있습니까?

@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://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Apache 역 프록시를 사용하여 이 솔루션을 적용하는 방법을 아는 사람이 있습니까?

내 VM에 설치된 RStudio 서버에서 이 솔루션을 실행하면 제대로 작동하지만 역 프록시가 구현된 프로덕션에 전달할 때 IP는 항상 127.0.0.1입니다.