CMSContext.CurrentUser is not updated after UserInfoProvider.SetPassword is called when using SQL Se

Drew Null asked on August 26, 2014 23:15

My setup is Kentico CMS 7.0.83 using SQL Server 2012 for session state. Note that the behavior in question does not occur when using InProc session state. And that I have only tested SQL Server and InProc.

CMSContext.CurrentUser password is not updated when the current user's password is changed via UserInfoProvider.SetPassword. It is pretty easy to reproduce. See the code below. You can also split the SetPassword and IsUserPasswordDifferent calls into multiple postbacks (and possibly multiple requests) and get the same result.

string newPassword = "newPassword";

UserInfoProvider.SetPassword(CMSContext.CurrentUser.UserName, newPassword);

bool isDifferent = UserInfoProvider.IsUserPasswordDifferent(CMSContext.CurrentUser, newPassword);

// isDifferent is true (!?)

My use case is that the if the user changes his or her password twice in a row, it bombs out on the second try. My workaround is to load the current user's UserInfo seperately through UserInfoProvider.GetUserInfo, and then pass that into IsUserPasswordDifferent.

I dotPeeked into CMS.SiteProvider and found that UserInfo.GetValue("UserPassword"), which returns the hashed password, is what appears to be out of sync.

So...

string newPassword = "newPassword";

UserInfoProvider.SetPassword(CMSContext.CurrentUser.UserName, newPassword);

UserInfo userInfo = UserInfoProvider.GetUserInfo(CMSContext.CurrentUser.UserName);

string passwordHash1 = CMSContext.CurrentUser.GetValue("UserPassword").ToString();

string passwordHash2 = userInfo.GetValue("UserPassword").ToString();

// passwordHash1 and passwordHash2 are different (!?)

Why isn't CMSContext.CurrentUser updated? And why does this only happen when I'm using SQL Server for session state?

Is there a best practice way to do what I'm trying to do?

Recent Answers

Brenden Kehren answered on August 27, 2014 14:49

Is there a chance the CurrentUser isn't updated because they would then be invalidated and required to log in again? So maybe it's cached?

0 votesVote for this answer Mark as a Correct answer

Drew Null answered on August 27, 2014 21:18

That would be understandable if this behavior occurred in both InProc and SQL Server session state, but it only happens to the latter...

string newPassword = "newPassword";

UserInfoProvider.SetPassword(CMSContext.CurrentUser.UserName, newPassword);

UserInfo userInfo = UserInfoProvider.GetUserInfo(CMSContext.CurrentUser.UserName);

string passwordHash1 = CMSContext.CurrentUser.GetValue("UserPassword").ToString();

string passwordHash2 = userInfo.GetValue("UserPassword").ToString();

// If session state is InProc, passwordHash1 and passwordHash2 are the same. 
// Both = the new password (set by the UserInfoProvider.SetPassword call).

// If session state is SQL Server, passwordHash1 and passwordHash2 are different:
// passwordHash1 is the old password (from CMSContext.CurrentUser, which mysteriously wasn't updated)
// passwordHash2 is the new password (set by the UserInfoProvider.SetPassword call).

0 votesVote for this answer Mark as a Correct answer