Различия в тайм-аутах auth и тайм-ауте сеанса
Тайм-аут состояния сеанса устанавливается с помощью этого элемента web.config
<sessionState mode="InProc" cookieless="false" timeout="120" />
Формы auth настраиваются с использованием этого элемента web.config
<system.web>
<authentication mode="Forms">
<forms loginUrl="Login.aspx"
protection="All"
timeout="30"
name=".ASPXAUTH"
path="/"
requireSSL="false"
slidingExpiration="true"
defaultUrl="default.aspx"
cookieless="UseDeviceProfile"
enableCrossAppRedirects="false" />
</authentication>
</system.web>
В чем разница между таймаутами, указанными в каждом из этих элементов? Если они разные, как это работает?
Ответы
Ответ 1
Сессия начинается каждый раз, когда новый пользователь попадает на веб-сайт, независимо от того, анонимно они анонимны. Аутентификация имеет очень мало общего с сеансом.
Тайм-аут проверки подлинности - это время, в течение которого cookie аутентификации подходит для пользовательского браузера. По истечении срока действия файла cookie они должны повторно аутентифицироваться для доступа к защищенным ресурсам на сайте.
Итак, если сеанс заканчивается перед файлом аутентификации - они все еще аутентифицированы, но все их переменные сеанса исчезают и могут вызывать ошибки на вашем веб-сайте, если вы не дисциплинированы при проверке нулей и других условий, вызванных отсутствием сеанса.
Если время проверки подлинности истекает перед сеансом, все их переменные сеанса все равно будут существовать, но они не смогут получить доступ к защищенным ресурсам, пока они снова не войдут в систему.
Ответ 2
как ожидалось.
например. если ваша сессия истечет через 20 минут, ваши переменные сеанса будут потеряны.
но пользователь может получить доступ к страницам, которые защищены аутентификацией.
если время ожидания аутентификации, пользователь не смог получить доступ к защищенной странице, а состояние сеанса не имеет значения.
Ответ 3
Значение таймаута сеанса должно быть меньше тайм-аута FormsAuthentication. Поскольку сеанс можно удалить из-за причины, и сценарий не будет работать.
Если сеанс закончится, проверьте билет FormsAuthentication. Если билет действителен, а не тайм-аут, повторите создание сеанса на странице входа в систему (определенный в файле web.config как параметр LoginUrl параметров FormsAuthentication).
Если FormsAuthentication не работает, ASP.NET FormsAuthentication автоматически перенаправляет пользователя на страницу входа, и пользователь должен снова войти в систему.
Не забывайте, что FormsAuthentication автоматически перенаправляет пользователя на страницу входа в систему при выходе из системы.
На самом деле я предпочитаю эту структуру:
- Создайте BasePage.cs для необходимых страниц.
-
в Page_Init в BasePage.cs проверьте сеанс. Если сеанс истек; перенаправить пользователя на страницу входа.
if (Session [ "UserId" ] == null) Response.Redirect( "Login.aspx", true);
-
В Page_Load в Login.aspx проверьте правильность времени билета Session и FormsAuthentication.
//User already have a session; redirect user to homepage.
if (SessionHandler.UserId != 0)
Response.Redirect("HomePage.aspx");
else
{
//Session is killed; check Ticket is Valid or not
if (Context.User.Identity != null && Context.User.Identity.IsAuthenticated)
{
//Use Value of the FormsAuthentication
var customDataToCheck = Context.User.Identity.Name;
//Use value to check user is exist really and check db for user session
var user = CheckUserData(customDataToCheck);
if (user != null)
{
//Start Session here
SessionHandler.StartSession(user);
//Redirect user to page what you want.
Response.Redirect("HomePage.aspx?ref=regenerated_session");
}
}
}
-
в Login.aspx используйте FormsAuthentication для создания файлов cookie.
if (username == "testuser" & & password == "testpassword" ) { // Данные пользователя будут записываться в файл cookie, хранить данные пользователя, которые вы можете проверить, действителен или нет (например, Username или UserId).
System.Web.Security.FormsAuthentication.SetAuthCookie( "testUserData", keepMeSignedInCheckBox.Checked); Response.Redirect( "HomePage.aspx" ); }