Shinyproxy: [Rapport de bogue] Erreur Ajax après une longue période d'inactivité avec l'authentification activée

Créé le 25 mars 2019 · 9Commentaires · Source: openanalytics/shinyproxy

Par exemple, disons que vous avez l'application simple ci-dessous. Notez que la table DT utilise ajax lorsque server = TRUE (le mode de traitement du serveur).

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))

Lorsque l'authentification est activée (toutes les méthodes d'authentification), vous ouvrez le navigateur et entrez dans l'application et tout fonctionne correctement (par exemple, cliquez sur le bouton de la page sous le tableau). Cependant, après une longue période d'inactivité (30 minutes ou 1 heure), cliquez sur le bouton de la page, vous trouverez les plaintes DT concernant l'erreur ajax. La façon de résoudre est simple : actualisez la page ou ouvrez simplement une nouvelle connexion à Shinyproxy et effectuez la reconnexion. Mais cela embrouille beaucoup les utilisateurs.

En effet, après une longue période d'inactivité, Shinyproxy vous oblige à vous reconnecter pour la nouvelle connexion, mais la connexion existante est toujours valide. Cela a pour effet secondaire que la publication AJAX que l'application existante tente d'effectuer sera rejetée par le serveur, car Shinyproxy la considère comme une nouvelle connexion ...

La façon de résoudre ce problème, je crois, est de

soit déconnectez les applications existantes chaque fois que la reconnexion l'exige (c'est-à-dire un délai d'attente), soit
reconnaître la connexion AJAX effectuée par l'application existante comme valide/autorisée...

Merci.

bug

Source

shrektan

Commentaire le plus utile

@shrektan J'ai eu des problèmes similaires, et OpenAnalytics m'a aidé à résoudre ce problème :
Modifiez le undertow timeout (qui est par défaut de 30 minutes).

server:
  servlet.session.timeout: 3600

Les ci-dessous sont en secondes - définissez-le sur 0 si vous n'avez pas de délai d'attente.
Merci Dylan

dylancis le 25 mars 2019

👍3

Tous les 9 commentaires

@shrektan J'ai eu des problèmes similaires, et OpenAnalytics m'a aidé à résoudre ce problème :
Modifiez le undertow timeout (qui est par défaut de 30 minutes).

server:
  servlet.session.timeout: 3600

Les ci-dessous sont en secondes - définissez-le sur 0 si vous n'avez pas de délai d'attente.
Merci Dylan

dylancis le 25 mars 2019

👍3

@dylancis Merci pour la solution de contournement ! Apprécié !

Cependant, je laisserai le problème ouvert car à mon humble avis, il est préférable de déconnecter l'application existante lorsque la session expire.

shrektan le 25 mars 2019

👍1

@dylancis BTW, un peu hors sujet, avez-vous essayé la nouvelle version de Shinyproxy avec les tables DT ? Je n'ai pas cherché la cause mais je vois les erreurs AJAX indiquant que les méthodes POST ne peuvent pas être acceptées.

shrektan le 25 mars 2019

@dylancis BTW, un peu hors sujet, avez-vous essayé la nouvelle version de Shinyproxy avec les tables DT ? Je n'ai pas cherché la cause mais je vois les erreurs AJAX indiquant que les méthodes POST ne peuvent pas être acceptées.

oups - non, je ne l'ai pas encore fait.

dylancis le 25 mars 2019

Aussi pour moi - je suis passé de 2.1 à 2.2 et maintenant même pas un seul renderDataTable fonctionne. Beaucoup d'erreurs AJAX me redirigeant vers cette page http://datatables.net/tn/7

DrumSergio le 26 mars 2019

👍1

Je crois que c'est un bug... En fait, ouvrez les outils de développement et vous pouvez voir la réponse de la requête AJAX - les méthodes POST ne peuvent pas être acceptées par le serveur mais GET est ok...

shrektan le 26 mars 2019

Salut @shrektan avez-vous soulevé ce problème d'abricot à propos de DT ? Nous prévoyons de mettre à niveau, mais nos applications dépendent fortement de la bibliothèque de tables de données.

dylancis le 27 mars 2019

@dylancis vient de déposer un nouveau problème sur ce bug au n°140

shrektan le 28 mars 2019

Comme @dylancis l'a mentionné, augmenter server.servlet.session.timeout évitera ce problème.
Mais je suis d'accord qu'il serait préférable que le délai d'expiration de la session soit retardé automatiquement tant qu'il y a un canal websocket ouvert (ce qui déclenche le rythme cardiaque et maintient ainsi le conteneur en vie).

Remarque : ce commentaire concerne l'expiration de la session, ce qui entraîne 401 réponses (non autorisées). Il ne s'agit pas du problème ajax POST entraînant 405 réponses (méthode non autorisée).