Shinyproxy: [Informe de error] Error de Ajax después de mucho tiempo inactivo con la autenticación habilitada

Creado en 25 mar. 2019 · 9Comentarios · Fuente: openanalytics/shinyproxy

Por ejemplo, digamos que tiene la siguiente aplicación simple. Tenga en cuenta que la tabla DT usa ajax cuando server = TRUE (el modo de procesamiento del servidor).

library(shiny)
ui <- fluidPage(DT::DTOutput('tbl'))
server <- function(input, output, session) {
  output$tbl <- DT::renderDT(iris, server = TRUE)
}
runApp(list(ui = ui, server = server))

Cuando tiene la autenticación habilitada (cualquier método de autenticación), abre el navegador e ingresa a la aplicación y todo funciona bien (como hacer clic en el botón de página debajo de la tabla). Sin embargo, después de mucho tiempo inactivo (30 minutos o 1 hora), haga clic en el botón de la página y encontrará quejas de DT sobre el error ajax. La forma de resolverlo es simple: actualice la página o simplemente abra una nueva conexión a Shinyproxy y vuelva a iniciar sesión. Pero confunde mucho a los usuarios.

Esto se debe a que después de mucho tiempo inactivo, Shinyproxy requiere que vuelva a iniciar sesión para la nueva conexión, pero la conexión existente sigue siendo válida. Tiene el efecto secundario de que la publicación AJAX que la aplicación existente intenta realizar será rechazada por el servidor, porque Shinyproxy la considera como una nueva conexión ...

Creo que la forma de resolver esto es

desconecte las aplicaciones existentes siempre que el re-inicio de sesión requiera (también conocido como un tiempo de espera), o
reconocer la conexión AJAX realizada por la aplicación existente como válida / autorizada ...

Gracias.

bug

Fuente

shrektan

Comentario más útil

@shrektan Tuve problemas similares y OpenAnalytics me ayudó a solucionarlo:
Cambie el tiempo undertow espera

server:
  servlet.session.timeout: 3600

Los siguientes están en segundos: configúrelo en 0 si no agota el tiempo de espera.
Gracias Dylan

dylancis en 25 mar. 2019

👍3

Todos 9 comentarios

@shrektan Tuve problemas similares y OpenAnalytics me ayudó a solucionarlo:
Cambie el tiempo undertow espera

server:
  servlet.session.timeout: 3600

Los siguientes están en segundos: configúrelo en 0 si no agota el tiempo de espera.
Gracias Dylan

dylancis en 25 mar. 2019

👍3

@dylancis ¡ Gracias por la solución! ¡Apreciado!

Sin embargo, dejaré el problema abierto porque, en mi humilde opinión, es mejor desconectar la aplicación existente cuando se agote el tiempo de espera de la sesión.

shrektan en 25 mar. 2019

👍1

@dylancis Por cierto, un poco fuera del tema, ¿has probado la nueva versión de Shinyproxy con tablas DT? No he investigado la causa, pero veo los errores AJAX que dicen que no se pueden aceptar los métodos POST.

shrektan en 25 mar. 2019

@dylancis Por cierto, un poco fuera del tema, ¿has probado la nueva versión de Shinyproxy con tablas DT? No he investigado la causa, pero veo los errores AJAX que dicen que no se pueden aceptar los métodos POST.

oups - no, todavía no.

dylancis en 25 mar. 2019

También para mí: hice la transición de 2.1 a 2.2 y ahora ni siquiera funciona un solo renderDataTable . Muchos errores de AJAX me redirigen a esta página http://datatables.net/tn/7

DrumSergio en 26 mar. 2019

👍1

Creo que es un error ... En realidad, abra las herramientas de desarrollo y podrá ver la respuesta de la solicitud AJAX: el servidor no puede aceptar los métodos POST, pero GET está bien ...

shrektan en 26 mar. 2019

Hola @shrektan, ¿has planteado este problema del albaricoque sobre DT? Estamos planeando actualizar, pero nuestras aplicaciones dependen en gran medida de la biblioteca de tablas de datos.

dylancis en 27 mar. 2019

@dylancis Acaba de presentar un nuevo número sobre este error en el n. ° 140

shrektan en 28 mar. 2019

Como mencionó @dylancis , aumentar server.servlet.session.timeout evitará este problema.
Pero estoy de acuerdo en que sería mejor si el tiempo de espera de la sesión se retrasa automáticamente siempre que haya un canal websocket abierto (que activa el latido del corazón y, por lo tanto, mantiene vivo el contenedor).

Nota: este comentario trata sobre la expiración de la sesión que resulta en respuestas 401 (no autorizadas). No se trata del problema POST de ajax que resulta en respuestas 405 (método no permitido).