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 من داخل وظيفة الخادم.

هذا من شأنه أن يكون مرشحا جيدا للحصول على الإصدار القادم من لامعة خادم المصدر المفتوح (ج جalandipertshalutiwari) ولكن بالتأكيد لن يكون هناك إطلاق آخر قبل rstudio :: أسيوط في أوائل فبراير شباط. حتى شهرين على الأقل. آسف ، لا يمكنني تحديد أكثر من ذلك.

@ 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

هل يعرف شخص ما كيفية تطبيق هذا الحل باستخدام وكيل عكسي اباتشي؟

إذا قمت بتشغيل هذا الحل على خادم RStudio المثبت على جهاز VM الخاص بي ، فإنه يعمل بشكل جيد ، ولكن عندما أقوم بتمريره إلى الإنتاج ، حيث يتم تطبيق وكيل عكسي ، يكون عنوان IP دائمًا 127.0.0.1