Я не могу не думать, что страшно использовать сессию asp.net, особенно с формами-авторизацией - потому что пользователь получает 2 куки: сессию и авторизацию. Представьте, что произойдет, если аутентифицированный пользователь A каким-то образом украдет cookie сеанса у аутентифицированного пользователя B: это приведет к тому, что пользователь A получит доступ ко всем данным, которыми владеет пользователь B (если только ваш код не проверяет, владеет ли идентификатор пользователя из auth-cookie объект сеанса, Другими словами, я бы предложил избавиться от сеанса или, по крайней мере, добавить значение идентификатора пользователя в объект сеанса и убедиться, что вы проверяете, что идентификатор пользователя из auth-cookie совпадает с идентификатором в событии application_authorize, возможно. не просил эту информацию, но я думаю, что это уместно, несмотря ни на что.
Поскольку сеанс и файлы cookie авторизации имеют мало общего друг с другом, что касается браузера, и ваша цель состоит в том, чтобы поддерживать сеанс в рабочем состоянии, в то время как срок действия файла cookie аутентификации должен истечь, тогда вы можете решить эту проблему, написав кусок JS (подсказка: window.setInterval), который регулярно пингует некоторые АНОНИМНЫЕ 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 обратно на 0 (или об отмене, а затем повторной инициализации событий интервала и тайм-аута). Другими словами, вы не можете начать измерять неактивность с момента загрузки страницы — вы должны сбрасывать счетчик неактивности при каждом действии пользователя (клике или, по крайней мере, при каждом обратном вызове ajax).
То, что я предлагаю здесь, может быть излишеством. Я бы, наверное, попытался решить это по-другому. Я бы попытался удалить сеанс в процессе из изображения и перезагрузить его на основе идентификатора пользователя auth-cookie из любого места, где бы ни находились пользовательские данные, каждый раз, когда это необходимо (или один раз для каждого запроса). Я не знаю, почему так важно держать объект сеанса висящим в памяти, даже когда пользователь вышел из системы (откуда вы знаете, что они не уйдут в течение недели; сохранение сеансов в живых убило бы ваш сервер, если бы вы большое количество пользователей). Возможно, хранить данные сеанса в базе данных или каком-либо другом механизме кэширования в сети (например, memcached) и извлекать их один раз для каждого запроса (например, в application_authorize), сохранять их в request.context (чтобы исключить многократное извлечение из нескольких мест). Затем срок действия вашего файла cookie для авторизации истечет, и используйте JS для открытия диалогового окна входа в систему за несколько минут до истечения срока действия файла cookie для аутентификации (чтобы избежать пробела, когда пользователь попадет на страницу входа в систему, если он нажмет на ссылку, если вы заботитесь об этом четное).
Я надеюсь, что эти идеи помогут.
person
Community
schedule
26.01.2012
