Shinyproxy: [Bug Report] Ajax error after long time idle with auth enabled

Created on 25 Mar 2019 · 9Comments · Source: openanalytics/shinyproxy

For example, let's say you have the below simple app. Note that the DT table uses ajax when server = TRUE (the server processing mode).

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

When with auth enabled (any auth methods), you open the browser and enter the app and everything works fine (like click the page button below the table). However, after long time idle (30 mins or 1 hour), click the page button you will find DT complaints the ajax error. The way to solve is simple: refresh the page or just open a new connection to Shinyproxy and perform the re-login. But it confuses the users a lot.

This is because after long time idle, Shinyproxy requires you to re-login for the new connection but the existing connection is still valid. It has the side-affect that the AJAX posting which the existing app trying to perform will be rejected by the server, because Shinyproxy regards it as a new connection...

The way to solve this I believe is to

either disconnect the existing apps whenever the re-login requires (a.k.a, a timeout), or
recognize the AJAX connection performed by the existing app as valid / authorized...

Thanks.

bug

Source

shrektan

Most helpful comment

@shrektan I had similar issues, and OpenAnalytics helped me to fix this:
Change the undertowtimeout (which by default is 30 minutes).

server:
  servlet.session.timeout: 3600

The below are in seconds - set it to 0 if you do not ant any timeout.
Thanks, Dylan

dylancis on 25 Mar 2019

👍3

All 9 comments

@shrektan I had similar issues, and OpenAnalytics helped me to fix this:
Change the undertowtimeout (which by default is 30 minutes).

server:
  servlet.session.timeout: 3600

The below are in seconds - set it to 0 if you do not ant any timeout.
Thanks, Dylan

dylancis on 25 Mar 2019

👍3

@dylancis Thanks for the workaround! Appreciated!

However, I'll leave the issue open because IMHO, it's better to disconnect the existing app when the session is timeout.

shrektan on 25 Mar 2019

👍1

@dylancis BTW, a little off-topic, have you tried the new release of Shinyproxy with DT tables? I haven't looked into the cause but I see the AJAX errors saying POST methods can't be accepted.

shrektan on 25 Mar 2019

@dylancis BTW, a little off-topic, have you tried the new release of Shinyproxy with DT tables? I haven't looked into the cause but I see the AJAX errors saying POST methods can't be accepted.

oups - no I did not yet.

dylancis on 25 Mar 2019

Also for me - I transitioned from 2.1 to 2.2 and now not even a single renderDataTable works. A lot of AJAX errors redirecting me to this page http://datatables.net/tn/7

DrumSergio on 26 Mar 2019

👍1

I believe it’s a bug... Actually, open the developer tools and you can see the respond of the AJAX request - POST methods can't be accepted by the server but GET is ok...

shrektan on 26 Mar 2019

Hi @shrektan have you raised this apricot issue about DT ? We are planning to upgrade but our apps relies heavily on datatable library.

dylancis on 27 Mar 2019

@dylancis Just filed a new issue about this bug at #140

shrektan on 28 Mar 2019

As @dylancis mentioned, increasing server.servlet.session.timeout will avoid this issue.
But I agree that it would be better if the session timeout is delayed automatically as long as there is an open websocket channel (which triggers heartbeat and thus keeps the container alive).

Note: this comment is about session expiration resulting in 401 (unauthorized) responses. It is not about the ajax POST issue resulting in 405 (method not allowed) responses.