Tengo una aplicación brillante dentro del servicio de aplicaciones de Azure que usa EasyAuth de Azure. Puedo autenticar con éxito para abrir una página. Sin embargo, me gustaría obtener la información del usuario, que no es automática, ya que Shiny elimina los encabezados sin comprar la edición profesional completa.
Puedo pensar en algunas posibles soluciones alternativas de alto nivel, pero no estoy seguro de qué tan bien, en todo caso, cualquiera de estas funcionaría sin intentar implementar cada una por completo.
Coloque un proxy inverso nginx o apache frente a Shiny que reescribiría los encabezados para consultar los parámetros a los que luego se podría acceder como session[['clientData']]$url_search Pro: Estoy bastante seguro de que esto funcionaría. Con: Creo que las personas podrían falsificar quiénes son simplemente cambiando la consulta en su dirección y también verían su nombre adjunto a la URL, lo que haría que copiar y pegar fuera una molestia. Esto no es un factor decisivo porque es solo por conveniencia, no por seguridad, todos tienen acceso a todo de todos modos (al menos por ahora)
Acceda a la cookie Secure&HTTPonly AppServiceAuthSession desde el servidor y luego httr::GET myurl.com/.auth/me usando esa cookie para obtener un json conciso de quién es el usuario. Pro: si es posible, entonces no tengo que volver a configurar mi imagen de Docker como en el n. ° 1 Contras: no parece que pueda colocar fácilmente la cookie en el brillante, por lo que es posible que esto no sea realmente un potencial
Haga que el navegador del cliente acceda a myurl.com/.auth/me a través de un script js y devuelva esos resultados al servidor brillante. Pro: Como 2, no requeriría reconfigurar mi servicio de aplicaciones. Con: No sé si es posible, pero es el mismo dominio, así que creo que lo es.
Sería más útil si 2 y 3 pudieran implementarse rápidamente o descartarse al 100%. Si hay una cuarta opción en la que no había pensado, también sería bienvenida.
Terminé descifrando el #3.
Aquí está el código R/Shiny
library(shiny) library(rjson) library(shinyjs) addResourcePath("www", "www") shinyApp( ui=( fluidPage( tags$head( tags$script(src = "www/script.js") ), useShinyjs(), verbatimTextOutput("results") ) ), server = function(input, output, session) { shinyjs::runjs('fetchUser();') output$results = renderPrint({ parsed<-try(fromJSON(json_str=input$username)) if(!any(class(parsed)=="try-error")) return(parsed[[1]]$user_id) }) } ) Aquí está el script.js que iría en una carpeta www
// script.js async function fetchUser() { let response = await fetch('/.auth/me'); if (response.status ===200) { let data = await response.text(); Shiny.setInputValue('username', await data); } } Improvisé esto junto con el libro JS para R , esta guía sobre la búsqueda de la función JS y algunas preguntas dispares sobre shinyjs . Supongo que si alguien realmente quisiera, podría interceptar ese script JS para devolver lo que quisiera en lugar de lo que proviene de /.auth/me, pero dado que eso solo es posible después de validar la autenticación AD y, en mi caso, es principalmente por comodidad, no por seguridad, no me preocupa demasiado. La buena noticia es que el json devuelto da un token cuya identidad, creo, podría verificarse de forma independiente.