Не могу не подумать, что страшно использовать сессию asp.net, особенно с form-auth - потому что пользователь получает 2 куки: сессию и авторизацию. Представьте себе, что произойдет, если каким-то образом аутентифицированный пользователь A украдет cookie сеанса у аутентифицированного пользователя B: это приведет к тому, что у пользователя A будет доступ ко всем данным, которыми владеет пользователь B (если ваш код не проверяет, владеет ли идентификатор пользователя из auth-cookie объект сеанса. Другими словами, я бы предложил избавиться от сеанса или, по крайней мере, добавить значение идентификатора пользователя к объекту сеанса и убедиться, что вы проверяете, совпадает ли идентификатор пользователя из файла auth-cookie с событием application_authorize, возможно. не просил эту информацию, но я думаю, что это уместно, независимо от того.
Поскольку сеанс и файлы cookie аутентификации имеют мало общего между браузером, и ваша цель состоит в том, чтобы поддерживать сеанс в действии, в то время как срок действия файла cookie аутентификации должен истечь, тогда вы можете решить это, написание фрагмента JS (подсказка: window.setInterval), который регулярно пингует некоторый ANONYMOUS url (aspx-страницу) на вашем сервере (убедитесь, что вы добавили случайный запрос к этим запросам; например, new Date().getTime()). Страница anon aspx должна будет прочитать (не писать!) Какое-то значение из сеанса (или просто извлечь объект сеанса) - просто чтобы сохранить его живым (возможно, это не является действительно необходимым; сделайте эксперимент), но браузер БУДЕТ отправлять файл cookie сеанса asp.net с этими запросами, чтобы вы могли таким образом поддерживать объект сеанса вечным.
С другой стороны, срок действия вашего файла cookie истекает. Однако вы ДОЛЖНЫ установить в настройках web.config (аутентификация> формы) НЕ ИСПОЛЬЗОВАНИЕ скользящего истечения (так как этот режим существенно продлевает срок действия / истечение срока действия файла cookie для аутентификации на другие минуты вне зависимости от времени ожидания). Затем вы можете быть уверены, что после истечения срока действия файла cookie (например, через 20 минут), когда пользователь нажимает защищенную ссылку (ну, ссылку, которая ссылается на защищенную страницу; неанон-страницу), он попадает при входе в систему. стр. Я знаю, что ты не хочешь этого. Итак, чтобы решить это, добавьте еще один (независимый) фрагмент javascript (подсказка: window.setTimeout([code], 2 * 60 * 1000) // to fire after 2 min since the page-load), чтобы запустить диалог входа в систему. Диалог входа в систему расширил бы auth-cookie, разместив uid / pwd и позволив asp.net проверить его.
Еще одна вещь: если у вас есть ajax на этой странице, вы должны подумать о сбросе этих js timeout обратно в 0 (или об отмене, а затем повторной инициализации интервала и событий timeout). Другими словами, вы не можете начать измерять неактивность с момента загрузки страницы - вы должны сбрасывать счетчик неактивности при каждом действии пользователя (щелчок; или, по крайней мере, при каждом обратном вызове ajax).
То, что я предлагаю здесь, может быть излишним. Я, вероятно, попытался бы решить это по-другому. Я попытался бы исключить внутрипроцессный сеанс из картинки и перезагрузить его на основе идентификатора пользователя auth-cookie из всех пользовательских данных, каждый раз, когда это необходимо (или один раз для каждого запроса). Я не знаю, почему так важно, чтобы объект сеанса зависал в памяти, даже когда пользователь вышел из системы (откуда вы знаете, что они не будут уходить в течение недели; поддержание сеансов в живых будет убивать ваш сервер, если вы большое количество пользователей). Может быть, сохранить данные сеанса в базе данных или какой-либо другой механизм кэширования в сети (например, memcached) и извлекать их один раз за запрос (например, в application_authorize), сохранять их в request.context (чтобы исключить его многократное извлечение из нескольких мест). Затем срок действия вашего auth-cookie истечет, и используйте JS, чтобы открыть диалоговое окно входа в систему за несколько минут до истечения срока действия auth cookie (чтобы избежать разрыва, в котором пользователь попадет на страницу входа, если он нажмет на ссылку, если вы заботитесь об этом даже).
Надеюсь, эти идеи помогут.