Shinyproxy: [Отчет об ошибке] Ошибка Ajax после длительного простоя с включенной аутентификацией

Созданный на 25 мар. 2019 · 9Комментарии · Источник: openanalytics/shinyproxy

Например, предположим, что у вас есть следующее простое приложение. Обратите внимание, что таблица DT использует ajax, когда server = TRUE (режим обработки сервера).

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

Когда включена аутентификация (любые методы аутентификации), вы открываете браузер и входите в приложение, и все работает нормально (например, нажмите кнопку страницы под таблицей). Однако после длительного простоя (30 минут или 1 час) нажмите кнопку страницы, и вы увидите, что DT жалуется на ошибку ajax. Способ решения прост: обновите страницу или просто откройте новое соединение с Shinyproxy и выполните повторный вход. Но это сильно сбивает с толку пользователей.

Это связано с тем, что после длительного простоя Shinyproxy требует, чтобы вы повторно вошли в систему для нового соединения, но существующее соединение по-прежнему действует. У этого есть побочный эффект, заключающийся в том, что публикация AJAX, которую пытается выполнить существующее приложение, будет отклонена сервером, потому что Shinyproxy рассматривает это как новое соединение ...

Я считаю, что способ решить эту проблему -

либо отключите существующие приложения всякий раз, когда потребуется повторный вход (он же тайм-аут), либо
распознавать соединение AJAX, выполняемое существующим приложением, как действительное / авторизованное ...

Спасибо.

bug

Источник

shrektan

Самый полезный комментарий

@shrektan У меня были похожие проблемы, и OpenAnalytics помог мне это исправить:
Измените тайм-аут undertow (по умолчанию 30 минут).

server:
  servlet.session.timeout: 3600

Ниже указано значение в секундах - установите значение 0 если у вас нет тайм-аута.
Спасибо, Дилан

dylancis 25 мар. 2019

👍3

Все 9 Комментарий

server:
  servlet.session.timeout: 3600

Ниже указано значение в секундах - установите значение 0 если у вас нет тайм-аута.
Спасибо, Дилан

dylancis 25 мар. 2019

👍3

@dylancis Спасибо за обходной путь! Оценил!

Однако я оставлю проблему открытой, потому что IMHO, лучше отключить существующее приложение, когда время ожидания сеанса.

shrektan 25 мар. 2019

👍1

@dylancis Кстати, немного не по теме, вы пробовали новую версию Shinyproxy с таблицами DT? Я не изучал причину, но вижу ошибки AJAX, в которых говорится, что методы POST не могут быть приняты.

shrektan 25 мар. 2019

@dylancis Кстати, немного не по теме, вы пробовали новую версию Shinyproxy с таблицами DT? Я не изучал причину, но вижу ошибки AJAX, в которых говорится, что методы POST не могут быть приняты.

упы - нет я еще не делал.

dylancis 25 мар. 2019

Также для меня - я перешел с 2.1 на 2.2, и теперь ни один renderDataTable работает. Многие ошибки AJAX перенаправляют меня на эту страницу http://datatables.net/tn/7

DrumSergio 26 мар. 2019

👍1

Я считаю, что это ошибка ... На самом деле, откройте инструменты разработчика, и вы увидите ответ на запрос AJAX - методы POST не могут быть приняты сервером, но GET в порядке ...

shrektan 26 мар. 2019

Привет, @shrektan , вы поднимали этот абрикосовый вопрос по поводу DT? Мы планируем обновление, но наши приложения в значительной степени полагаются на библиотеку данных.

dylancis 27 мар. 2019

@dylancis Только что

shrektan 28 мар. 2019

Как упоминал @dylancis , увеличение server.servlet.session.timeout позволит избежать этой проблемы.
Но я согласен с тем, что было бы лучше, если бы тайм-аут сеанса откладывался автоматически, пока есть открытый канал веб-сокета (который запускает сердцебиение и, таким образом, поддерживает работу контейнера).

Примечание: этот комментарий касается истечения срока действия сеанса, в результате которого был получен 401 (неавторизованный) ответ. Речь идет не о проблеме с Ajax POST, которая приводит к 405-м ответам (метод запрещен).