Shiny: क्लाइंट डेटा पर क्लाइंट का आईपी पता उपलब्ध कराएं

इसके अलावा HTTP अनुरोध शीर्षलेख।

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

क्या इस पर कोई आंदोलन हुआ है? @jcheng5

@coatless नहीं, लेकिन आपको इसकी क्या ज़रूरत थी?

मेरे पास एक चमकदार एप्लिकेशन है जो छात्रों को होमवर्क जमा करने की अनुमति देने के लिए सेटअप है। ऐप अभी केवल उपयोगकर्ता नाम और कार्रवाई सबमिट करने के समय को रिकॉर्ड करने में सक्षम है। आईपी ​​​​पते के लिए अनुरोध शाइनी ऐप को दिया जा रहा है क्योंकि यह मुझे सबमिट किए गए असाइनमेंट के साथ उपयोगकर्ता के आईपी को स्टोर करने में सक्षम करेगा। यह मेरे वर्तमान सेटअप के तहत समान रूप से रैंक किए गए दो सबमिशन के कारण अकादमिक अखंडता उल्लंघन का समर्थन करने के लिए अतिरिक्त सबूत प्रदान करेगा।

अनुरोध को उजागर करने के लिए एक और वोट आईपी

एक और वोट।

यदि आपका ऐप 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 कैश किया जा रहा हो।

यदि आप धोखाधड़ी के बारे में बहुत चिंतित नहीं हैं तो ऐसा करने का एक अधिक विश्वसनीय तरीका आईपी पते को उत्पन्न यूआई में इंजेक्ट करना है। काश हमारे पास <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 वास्तव में मैंने एक नजदीकी नजर /etc/shiny-server/shiny-server.conf जोड़ना):

whitelist_headers "x-forwarded-for";

फिर आप सर्वर फ़ंक्शन के भीतर से session$req$HTTP_X_FORWARDED_FOR ढूंढ सकते हैं।

यह शाइनी सर्वर ओपन सोर्स (cc @alandipert @shalutiwari) के अगले संस्करण के लिए एक अच्छा उम्मीदवार होगा, लेकिन निश्चित रूप से फरवरी की शुरुआत में rstudio::conf से पहले कोई और रिलीज़ नहीं होगी। तो कम से कम एक दो महीने। क्षमा करें, मैं इससे अधिक विशिष्ट नहीं हो सकता।

@ jcheng5 उत्कृष्ट। एक हजार धन्यवाद दोस्त!

कोई बात नहीं, whitelist_headers काम नहीं करता--जिस कोडपथ पर यह काम करता है, उसके पहले सही हेडर नहीं होते हैं। मुझे देखने दो कि क्या मैं इसका पता लगा सकता हूं।

स्वयं को नोट्स (और @alandipert):

• नोड-http-प्रॉक्सी के लिए xfwd कार्यान्वयन आदर्श नहीं है; यहाँ देखें । यह मौजूदा X-Forwarded-For हेडर को संरक्षित नहीं करता है (यदि आप एक प्रॉक्सी हैं, तो आपको किसी भी मौजूदा X-Forwarded-For हेडर के अंत में रिमोट-एड्र जोड़ना होगा यदि अपस्ट्रीम प्रॉक्सी पर भरोसा किया जाता है ) आदर्श रूप से हम इसका उपयोग नहीं करेंगे बल्कि इसके बजाय इन शीर्षलेखों को lib/proxy/http.js में लागू करेंगे। संभवत: व्यवस्थापक हमें यह बताना चाहेंगे कि क्या अपस्ट्रीम प्रॉक्सी पर भरोसा किया जाता है (या बेहतर अभी तक, कौन से आईपी को विश्वसनीय प्रॉक्सी माना जाना चाहिए)।
• वेबसोकेट के लिए X-Forwarded-* को लागू करना सीधा है; सॉकजेएस इन शीर्षकों को अनुमति देता है। lib/proxy/sockjs.js , createWebSocketClient हेडर को इसके दूसरे तर्क के रूप में स्वीकार कर सकते हैं, और आप अनुरोध शीर्षलेखों को conn.$conn._conn.headers माध्यम से प्राप्त कर सकते हैं (जाहिर है हमें निजी क्षेत्रों को पढ़ने के बजाय एक्सेसर्स जोड़ना चाहिए)।

इस पर किसी भी अद्यतन? चमकदार के अंदर अनुरोध आईपी को उजागर करना काफी उपयोगी होगा।

क्लाइंट के आईपी पते तक पहुंच मेरी परियोजनाओं में भी वास्तव में उपयोगी होगी। किसी भी मौके पर हम इस सुविधा को आगामी रिलीज में देखेंगे?

यदि आपका ऐप Connect या Shinyapps.io का उपयोग करके परिनियोजित किया गया है, तो ऐसा करने का एक

library(shiny)

ui_xfwd <- NULL

ui <- function(req) {
...

क्या एक चमकदार मॉड्यूल के भीतर से अनुरोध जानकारी (यहां तक ​​​​कि एक हैकी तरीके से) तक पहुंचने का कोई तरीका है?

क्या एक चमकदार मॉड्यूल के भीतर से अनुरोध जानकारी (यहां तक ​​​​कि एक हैकी तरीके से) तक पहुंचने का कोई तरीका है?

@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

क्या कोई जानता है कि अपाचे रिवर्स प्रॉक्सी का उपयोग करके इस समाधान को कैसे लागू किया जाए?

अगर मैं अपने वीएम पर स्थापित RStudio सर्वर पर इस समाधान को चलाता हूं तो यह ठीक काम करता है, लेकिन जब मैं इसे उत्पादन में पास करता हूं, जहां मेरे पास रिवर्स प्रॉक्सी लागू होता है, आईपी हमेशा 127.0.0.1 होता है