Shiny: Сделать клиентский IP-адрес доступным в clientData

Также заголовки 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 заключается в том, что он предполагает, что всякий раз, когда запускается функция сервера, непосредственно предшествующий запрос пользовательского интерфейса был из того же браузера. Это не обязательно так - вполне возможно, что эти запросы не являются последовательными из-за перекрытия трафика или, возможно, пользовательский интерфейс кэшируется, когда пользователь нажимает кнопку возврата.

Если вас не слишком беспокоит мошенничество, более надежный способ сделать это - ввести 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), но, конечно, не будет другого выпуска до rstudio :: conf в начале февраля. Так что минимум пару месяцев. Извините, я не могу уточнить, чем это.

@ jcheng5 отлично. Тысяча благодарностей, дружище!

Неважно, whitelist_headers не работают - кодовый путь, по которому он работает, изначально не имеет правильных заголовков. Дай мне посмотреть, смогу ли я разобраться в этом.

Примечания для себя (и @alandipert):

• Реализация xfwd для node-http-proxy не идеальна; см. здесь . Он не сохраняет существующие заголовки X-Forwarded-For (если вы прокси, вы должны добавить удаленный адрес в конец любого существующего заголовка X-Forwarded-For если прокси-сервер верхнего уровня является доверенным ). В идеале мы бы не использовали это, а вместо этого реализовали бы эти заголовки сами в lib/proxy/http.js . Вероятно, администратор может захотеть сообщить нам, является ли вышестоящий прокси-сервер доверенным (или, что еще лучше, какие IP-адреса следует считать доверенными прокси).
• Реализовать X-Forwarded-* для websocket несложно; 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 в его коде) через суб -модуль из основной функции пользовательского интерфейса.

Но теперь я вижу значение 127.0.0.1 даже при доступе с другого компьютера. Ожидается ли это?

Вроде НЕ ожидалось, но с пользователями иногда случается: https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Кто-нибудь знает, как применить это решение с помощью обратного прокси-сервера apache?

Если я запускаю это решение на сервере RStudio, установленном на моей виртуальной машине, оно работает нормально, но когда я передаю его в производство, где у меня реализован обратный прокси, IP всегда будет 127.0.0.1.