Shinyproxy: [Fehlerbericht] Ajax-Fehler nach langem Leerlauf mit aktivierter Authentifizierung

Erstellt am 25. März 2019 · 9Kommentare · Quelle: openanalytics/shinyproxy

Angenommen, Sie haben die folgende einfache App. Beachten Sie, dass die DT-Tabelle Ajax verwendet, wenn server = TRUE (der Server-Verarbeitungsmodus) verwendet wird.

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

Wenn die Authentifizierung aktiviert ist (beliebige Authentifizierungsmethoden), öffnen Sie den Browser und rufen die App auf und alles funktioniert einwandfrei (z. B. Klicken Sie auf die Seitenschaltfläche unter der Tabelle). Wenn Sie jedoch nach langer Zeit im Leerlauf (30 Minuten oder 1 Stunde) auf die Seitenschaltfläche klicken, finden Sie DT-Beschwerden den Ajax-Fehler. Die Lösung ist einfach: Aktualisieren Sie die Seite oder öffnen Sie einfach eine neue Verbindung zu Shinyproxy und führen Sie die erneute Anmeldung durch. Aber es verwirrt die Benutzer sehr.

Dies liegt daran, dass Shinyproxy nach längerer Inaktivität eine erneute Anmeldung für die neue Verbindung erfordert, die bestehende Verbindung jedoch weiterhin gültig ist. Es hat den Nebeneffekt, dass das AJAX-Posting, das die vorhandene App versucht durchzuführen, vom Server abgelehnt wird, da Shinyproxy es als neue Verbindung betrachtet ...

Der Weg, dies zu lösen, ist meiner Meinung nach

Trennen Sie entweder die vorhandenen Apps, wenn die erneute Anmeldung erforderlich ist (auch bekannt als Timeout), oder
erkennen die von der bestehenden App durchgeführte AJAX-Verbindung als gültig / autorisiert...

Vielen Dank.

bug

Quelle

shrektan

Hilfreichster Kommentar

@shrektan Ich hatte ähnliche Probleme und OpenAnalytics half mir, dies zu beheben:
Ändern Sie das undertow Timeout (das standardmäßig 30 Minuten beträgt).

server:
  servlet.session.timeout: 3600

Die folgenden sind in Sekunden - setzen Sie es auf 0 wenn Sie keine Zeitüberschreitung haben.
Danke, Dylan

dylancis am 25. März 2019

👍3

Alle 9 Kommentare

@shrektan Ich hatte ähnliche Probleme und OpenAnalytics half mir, dies zu beheben:
Ändern Sie das undertow Timeout (das standardmäßig 30 Minuten beträgt).

server:
  servlet.session.timeout: 3600

Die folgenden sind in Sekunden - setzen Sie es auf 0 wenn Sie keine Zeitüberschreitung haben.
Danke, Dylan

dylancis am 25. März 2019

👍3

@dylancis Danke für die

Ich lasse das Problem jedoch offen, da es IMHO besser ist, die vorhandene App zu trennen, wenn die Sitzung abgelaufen ist.

shrektan am 25. März 2019

👍1

@dylancis Übrigens , etwas abseits vom Thema, hast du die neue Version von Shinyproxy mit DT-Tabellen ausprobiert? Ich habe die Ursache nicht untersucht, aber ich sehe die AJAX-Fehler, die besagen, dass POST-Methoden nicht akzeptiert werden können.

shrektan am 25. März 2019

@dylancis Übrigens , etwas abseits vom Thema, hast du die neue Version von Shinyproxy mit DT-Tabellen ausprobiert? Ich habe die Ursache nicht untersucht, aber ich sehe die AJAX-Fehler, die besagen, dass POST-Methoden nicht akzeptiert werden können.

oups - nein habe ich noch nicht.

dylancis am 25. März 2019

Auch für mich - ich bin von 2.1 auf 2.2 umgestiegen und jetzt funktioniert nicht einmal ein einziges renderDataTable . Viele AJAX-Fehler, die mich auf diese Seite umleiten http://datatables.net/tn/7

DrumSergio am 26. März 2019

👍1

Ich glaube, es ist ein Fehler ... Öffnen Sie eigentlich die Entwicklertools und Sie können die Antwort der AJAX-Anfrage sehen - POST-Methoden können vom Server nicht akzeptiert werden, aber GET ist in Ordnung ...

shrektan am 26. März 2019

Hallo @shrektan, hast du dieses Aprikosenproblem über DT

dylancis am 27. März 2019

@dylancis Habe gerade ein neues Problem zu diesem Fehler unter #140 eingereicht

shrektan am 28. März 2019

Wie @dylancis erwähnt, wird dieses Problem durch Erhöhen von server.servlet.session.timeout vermieden .
Aber ich stimme zu, dass es besser wäre, wenn das Session-Timeout automatisch verzögert wird, solange ein offener Websocket-Kanal vorhanden ist (der Heartbeat auslöst und somit den Container am Leben hält).

Hinweis: Dieser Kommentar bezieht sich auf den Ablauf der Sitzung, der zu 401 (nicht autorisierten) Antworten führt. Es geht nicht um das Ajax-POST-Problem, das zu 405 Antworten (Methode nicht zulässig) führt.

fmichielssen am 29. März 2019

👍2

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Shinyproxy: [Fehlerbericht] Ajax-Fehler nach langem Leerlauf mit aktivierter Authentifizierung

Hilfreichster Kommentar

Alle 9 Kommentare

Verwandte Themen