Shiny: Jadikan alamat IP klien tersedia di clientData

Juga header permintaan HTTP.

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

Apakah ada gerakan yang terjadi pada ini? @jcheng5

@coatless Tidak, tapi untuk apa Anda membutuhkannya?

Saya memiliki aplikasi mengkilap yang disiapkan untuk memungkinkan siswa mengirimkan pekerjaan rumah. Aplikasi saat ini hanya dapat merekam nama pengguna dan waktu pengiriman pada pengiriman tindakan. Permintaan alamat IP yang diteruskan ke aplikasi mengkilap adalah karena itu akan memungkinkan saya untuk menyimpan IP pengguna bersama dengan tugas yang dikirimkan. Ini akan memberikan bukti tambahan untuk mendukung pelanggaran integritas akademik karena dua kiriman diberi peringkat yang sama di bawah pengaturan saya saat ini.

Suara lain untuk mengekspos permintaan IP

Namun suara lain.

Jika aplikasi Anda di-deploy menggunakan Connect atau shinyapps.io , ada sedikit cara untuk melakukan ini. Kami sedang berupaya membuat ini tidak terlalu mudah diretas dengan membuatnya dapat diakses dari sisi server (dan sama sekali di server yang mengkilap), jadi ini bukan kata terakhir tentang topik tersebut. Saya hanya ingin membagikan apa yang berfungsi hari ini jika itu berguna bagi Anda semua:

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)

Saya tidak akan melakukannya dengan cara ini--saya akan memposting solusi yang lebih kuat sebentar lagi.

@ jcheng5 ada eta pada metode yang kuat?

Maaf atas keterlambatannya. Masalah dengan metode oleh @bborgesr adalah bahwa ia mengasumsikan bahwa setiap kali fungsi server berjalan, permintaan UI yang mendahuluinya berasal dari browser yang sama. Itu belum tentu benar--sangat mungkin bahwa permintaan tersebut tidak berurutan karena lalu lintas yang tumpang tindih atau mungkin UI di-cache saat pengguna menekan tombol kembali.

Jika Anda tidak terlalu khawatir tentang penipuan, maka cara yang lebih andal untuk melakukannya adalah dengan memasukkan alamat IP ke UI yang dihasilkan. Saya berharap kami memiliki pengikatan input untuk <input type="hidden"> tetapi saat ini kami tidak memilikinya, jadi Anda dapat menyembunyikan input teks sebagai gantinya.

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)

Jika Anda lebih khawatir tentang penipuan maka sayangnya Anda harus menunggu perbaikan yang tepat untuk mendarat di produk server kami.

@ jcheng5 apakah ada ETA kapan perbaikan yang tepat akan mendarat? (1 bulan, 6 bulan, tahun?)

@coatless Sebenarnya saya melihat lebih dekat dan ini sepertinya sudah bekerja dengan Shiny Server Pro (menambahkan yang berikut ke /etc/shiny-server/shiny-server.conf ):

whitelist_headers "x-forwarded-for";

Kemudian Anda dapat mencari session$req$HTTP_X_FORWARDED_FOR dari dalam fungsi server.

Ini akan menjadi kandidat yang baik untuk versi berikutnya dari Shiny Server Open Source (cc @alandipert @shalutiwari) tetapi pasti tidak akan ada rilis lain sebelum rstudio::conf di awal Februari. Jadi setidaknya beberapa bulan. Maaf saya tidak bisa lebih spesifik dari itu.

@jcheng5 luar biasa. Seribu terima kasih sobat!

Tidak apa-apa, whitelist_headers tidak berfungsi--jalur kode yang dioperasikannya tidak memiliki header yang benar sejak awal. Biarkan saya melihat apakah saya bisa mengetahui hal ini.

Catatan untuk diri sendiri (dan @alandipert):

• Implementasi xfwd untuk node-http-proxy tidak ideal; lihat di sini . Itu tidak mempertahankan header X-Forwarded-For (jika Anda adalah proxy, Anda seharusnya menambahkan remote-addr ke akhir dari header X-Forwarded-For jika proxy upstream dipercaya ). Idealnya kami tidak akan menggunakan ini tetapi sebaliknya akan mengimplementasikan header ini sendiri di lib/proxy/http.js . Mungkin ingin administrator memberi tahu kami apakah proxy upstream tepercaya (atau lebih baik lagi, IP mana yang harus dianggap sebagai proxy tepercaya).
• Menerapkan X-Forwarded-* untuk websocket sangatlah mudah; SockJS memungkinkan tajuk ini lewat. Dalam lib/proxy/sockjs.js , createWebSocketClient dapat menerima header sebagai argumen kedua, dan Anda bisa mendapatkan header permintaan melalui conn.$conn._conn.headers (jelas kita harus menambahkan pengakses daripada membaca bidang pribadi).

Ada pembaruan tentang ini? Mengekspos IP permintaan di dalam mengkilap akan sangat berguna.

Memiliki akses ke alamat IP klien akan sangat berguna dalam proyek saya juga. Adakah kemungkinan kita akan melihat fitur ini di rilis mendatang?

Jika aplikasi Anda di-deploy menggunakan Connect atau shinyapps.io , ada sedikit cara untuk melakukan ini. Kami sedang berupaya membuat ini tidak terlalu mudah diretas dengan membuatnya dapat diakses dari sisi server (dan sama sekali di server yang mengkilap), jadi ini bukan kata terakhir tentang topik tersebut. Saya hanya ingin membagikan apa yang berfungsi hari ini jika itu berguna bagi Anda semua:

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

Apakah ada cara untuk mengakses informasi permintaan (bahkan dengan cara hacky) dari dalam Modul Shiny?

Apakah ada cara untuk mengakses informasi permintaan (bahkan dengan cara hacky) dari dalam Modul Shiny?

Pendekatan yang disarankan oleh @ jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-351857670) harus bekerja dari dalam modul (setelah didukung penuh)

Saya mendapat solusinya dengan @ jcheng5 (https://github.com/rstudio/shiny/issues/141#issuecomment-352564869) untuk bekerja dengan meneruskan lingkungan permintaan ( req dalam kodenya) melalui sub -modul dari fungsi ui utama.

Tapi sekarang saya melihat nilai 127.0.0.1, bahkan ketika diakses dari mesin yang berbeda. Apakah ini diharapkan?

Tampaknya TIDAK diharapkan, tetapi kadang-kadang terjadi pada pengguna: https://groups.google.com/d/msg/shiny-discuss/9WcbS3E4Cfc/9hRS6VDyTxYJ

Adakah yang tahu cara menerapkan solusi ini menggunakan proxy terbalik Apache?

Jika saya menjalankan solusi ini di server RStudio yang diinstal pada VM saya, ini berfungsi dengan baik, tetapi ketika saya meneruskannya ke produksi, di mana saya menerapkan proxy terbalik, IP selalu 127.0.0.1