Shinyproxy: [Relatório de Bug] Erro Ajax após muito tempo ocioso com autenticação habilitada

Criado em 25 mar. 2019 · 9Comentários · Fonte: openanalytics/shinyproxy

Por exemplo, digamos que você tenha o aplicativo simples abaixo. Observe que a tabela DT usa ajax quando server = TRUE (o modo de processamento do 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))

Quando com a autenticação habilitada (qualquer método de autenticação), você abre o navegador e entra no aplicativo e tudo funciona bem (como clicar no botão da página abaixo da tabela). No entanto, após um longo tempo ocioso (30 minutos ou 1 hora), clique no botão da página para encontrar as reclamações do DT sobre o erro de ajax. A maneira de resolver é simples: atualize a página ou apenas abra uma nova conexão com o Shinyproxy e execute o re-login. Mas confunde muito os usuários.

Isso ocorre porque, após um longo tempo ocioso, o Shinyproxy exige que você se conecte novamente para a nova conexão, mas a conexão existente ainda é válida. Isso tem o efeito colateral de que a postagem AJAX que o aplicativo existente está tentando executar será rejeitada pelo servidor, porque o Shinyproxy a considera como uma nova conexão ...

A maneira de resolver isso, acredito, é

desconecte os aplicativos existentes sempre que o novo login exigir (também conhecido como tempo limite) ou
reconhecer a conexão AJAX realizada pelo aplicativo existente como válida / autorizada ...

Obrigado.

bug

Fonte

shrektan

Comentários muito úteis

@shrektan Eu tive problemas semelhantes e OpenAnalytics me ajudou a consertar isso:
Altere o tempo limite de undertow (que por padrão é 30 minutos).

server:
  servlet.session.timeout: 3600

Os valores abaixo estão em segundos - defina-o como 0 se você não der nenhum tempo limite.
Obrigado Dylan

dylancis em 25 mar. 2019

👍3

Todos 9 comentários

@shrektan Eu tive problemas semelhantes e OpenAnalytics me ajudou a consertar isso:
Altere o tempo limite de undertow (que por padrão é 30 minutos).

server:
  servlet.session.timeout: 3600

Os valores abaixo estão em segundos - defina-o como 0 se você não der nenhum tempo limite.
Obrigado Dylan

dylancis em 25 mar. 2019

👍3

@dylancis Obrigado pela solução alternativa! Estimado!

No entanto, vou deixar o problema em aberto porque, IMHO, é melhor desconectar o aplicativo existente quando a sessão expirar.

shrektan em 25 mar. 2019

👍1

@dylancis BTW, um pouco fora do assunto, você experimentou a nova versão do Shinyproxy com tabelas DT? Não investiguei a causa, mas vejo erros AJAX dizendo que os métodos POST não podem ser aceitos.

shrektan em 25 mar. 2019

@dylancis BTW, um pouco fora do assunto, você experimentou a nova versão do Shinyproxy com tabelas DT? Não investiguei a causa, mas vejo erros AJAX dizendo que os métodos POST não podem ser aceitos.

oups - não, ainda não.

dylancis em 25 mar. 2019

Também para mim - fiz a transição do 2.1 para o 2.2 e agora nem mesmo um único renderDataTable funciona. Muitos erros de AJAX me redirecionando para esta página http://datatables.net/tn/7

DrumSergio em 26 mar. 2019

👍1

Acredito que seja um bug ... Na verdade, abra as ferramentas do desenvolvedor e você verá a resposta da solicitação AJAX - métodos POST não podem ser aceitos pelo servidor, mas GET está ok ...

shrektan em 26 mar. 2019

Olá @shrektan , você levantou essa questão do damasco sobre a TD? Estamos planejando atualizar, mas nossos aplicativos dependem muito da biblioteca de dados.

dylancis em 27 mar. 2019

@dylancis Acabou de apresentar um novo problema sobre este bug no # 140

shrektan em 28 mar. 2019

Como @dylancis mencionado, aumentar server.servlet.session.timeout evitará esse problema.
Mas eu concordo que seria melhor se o tempo limite da sessão fosse atrasado automaticamente, desde que houvesse um canal de websocket aberto (que dispara a pulsação e, portanto, mantém o contêiner ativo).

Nota: este comentário é sobre a expiração da sessão resultando em 401 respostas (não autorizadas). Não se trata do problema do POST ajax que resulta em 405 (método não permitido) respostas.