Почему сайт ASP.NET Sitecore отбрасывает сеанс через 7 или 8 минут?

У меня есть сайт Sitecore 7.5 с двумя внешними CD-серверами и балансировщиком нагрузки с липкими сессиями. По умолчанию балансировщик нагрузки имеет время ожидания 5 минут. Сайт Sitecore имеет значение времени ожидания сеанса ASP.NET по умолчанию 20 минут. Я получаю сообщения о том, что сайт случайно выводит людей из системы. Я только что провел следующий эксперимент:

  • Начался новый сеанс в новом браузере
  • Запустил таймер на моем телефоне
  • Практически постоянно нажимал на разные страницы сайта. Примерно самое долгое время, когда я бездействовал, составляло, возможно, 30 секунд.
  • Примерно через 10 - 15 минут я вдруг заметил, что больше не входил в приложение

Я не могу понять, почему это происходит. Это код, который я использую для входа в систему.

        protected void ButtonLogin_Click(object source, EventArgs e)
    {
        bool loginSuccess = Sitecore.Security.Authentication.AuthenticationManager.Login("extranet\\" + TextLoginUsername.Text, TextLoginPassword.Text, CheckKeepLoggedIn.Checked) || (Sitecore.Security.Authentication.AuthenticationManager.Login("sitecore\\" + TextLoginUsername.Text, TextLoginPassword.Text, CheckKeepLoggedIn.Checked));
        if (loginSuccess)
        {
            LabelLoginError.Visible = false;
            Sitecore.Analytics.Tracker.Current.Session.Identify(Sitecore.Context.GetUserName());
            Sitecore.Analytics.Tracker.Contact.Tags["Full Name"] = Sitecore.Context.GetUserName();
            Response.Redirect(ButtonLogin.PostBackUrl);
            return;
        }

        //Otherwise log as error.
        LabelLoginError.Text = "Username/password combination was incorrect.";
        LabelLoginError.Visible = true;
    }

Есть идеи?

3 ответа

Проверьте журналы, чтобы увидеть, перезапускается ли ваш домен приложения или пул приложений из-за файловой активности, таким образом теряя состояние сеанса inProc. Ищите "выключение" или "Sitecore запущен" в журналах.

Предыдущий ответ, неправильно прочитав вопрос

Вы входите в систему на компьютере A, но через 5 минут истекает ваш липкий сеанс с балансировщиком нагрузки, ваш следующий запрос начнет новый липкий сеанс и с 50% вероятностью будет перенаправлен на сервер A снова. Если он назначен серверу A, ваш опыт не пострадает, так как вы все еще вошли в систему на сервере A. Если вместо этого новый липкий сеанс назначен серверу B, то вы не вошли на сервер B, так что вы будете Я думаю, что вы вышли из системы, но на самом деле вы никогда не входили в систему на сервере B.

Чтобы это исправить, установите время ожидания сеанса балансировщика нагрузки таким же, как и время сеанса сервера - то есть 20 минут.

Липкий сеанс существует, чтобы гарантировать, что ваши запросы отправляются на тот же сервер. Задав длину сеанса балансировщика нагрузки, превышающую время ожидания сеанса сервера, вы создали 15-минутный дефицит, когда вы можете быть перенаправлены на неправильный сервер, в то время как ваш активный сеанс все еще существует на исходном сервере.

Установка html-комментария на вашей веб-странице с именем сервера или IP-адресом подтвердит это поведение.

Убедитесь, что ваша папка данных находится за пределами вашего webroot. Если ваши данные находятся в вашем webroot, это может привести к сбросу пула приложений из-за количества файлов, которые изменяются в папке данных, файлах журнала, кэше состояния просмотра, индексах lucene и т. Д.

См. Этот пост для получения дополнительной информации: http://www.sitecorenutsbolts.net/2015/06/01/Application-Pool-Restarts-when-Data-folder-is-in-Webroot/ - убедитесь, что ваша папка данных не находится в ваш

Вы проверили назначение на CD-сервер? Вы можете проверить это в консоли браузера. Может быть, срок действия файла cookie истек, а балансировщик нагрузки только что переключил сервер, который использовался вашим пользователем?

И еще одна вещь - вы используете SSL для безопасного соединения? В прошлом у одного из моих коллег / администраторов были некоторые проблемы с правильной настройкой LB с SSL.

Другие вопросы по тегам