Несколько недель назад один из наших клиентов связался с нами и сказал, что иногда, когда он создает действие, оно создается под чужим именем!
Мы устранили неполадки и ничего не нашли. Мы попросили пользователя связаться с нами в следующий раз, когда у него возникнут эти проблемы. Он действительно связался с нами, и мы смогли провести с ним встречу и увидеть проблему собственными глазами.
Это была не только деятельность, он был признан кем-то еще в приложении. У него был доступ ко всему, к чему должен был иметь доступ другой человек. Именно тогда мы поняли, что у нас проблема перепутанного сеанса.
Немного о нашем коде:
Как и в любом другом приложении, у нас есть простая страница входа, на которой пользователь вводит адрес электронной почты и пароль, и мы проверяем их подлинность в нашей базе данных, и если они действительны, мы вызываем FormsAuthentication.SetAuthCookie (), чтобы сохранить текущий идентификатор пользователя в файле cookie, и позволяем ему войти.
BL.User currentUser = BL.User.Authenticate(txtUsername.Text, txtPassword.Text);
if (currentUser != null)
{
this.Session["NumberOfLoginTried"] = "0";
FormsAuthentication.SetAuthCookie(currentUser.UserID.ToString(), chRememberMe.Checked);
Response.Redirect(FormsAuthentication.GetRedirectUrl(currentUser.UserID.ToString(), false));
}
Мы также используем следующий фрагмент кода для получения идентификатора вошедшего в систему пользователя (текущего пользователя) в нашем приложении.
public static int GetCurrentUserID()
{
int userID = -1;
int.TryParse(HttpContext.Current.User.Identity.Name, out userID);
return userID;
}
И да, мы выполнили нашу домашнюю работу, погуглили и увидели следующие две ссылки:
http: //lionsden.co.il/codeden/?p=446
Перепутывание сеанса ASP.NET с использованием StateServer (СТРАШНО!)
Мы отключили кэширование в режиме ядра и кэширование в пользовательском режиме для файлов .aspx и. ascx файлы, и это все еще происходит.
PS - Приложение работает в Windows 2008 R2 с IIS 7.5. И мы НЕ используем сеанс без файлов cookie.