Last week I was implementing the “data moving” feature, which lets you move the data from a Provider to another. You can already move Pages and their associated data (Categories, Snippets, etc.); all seems to work fine.
When I started writing the code to do the same thing for Users I though “It will be trivial compared to Pages [that required a hundred LOC], there is only a list of users to move”. Then, I realized that Users cannot be moved. I don’t know how couldn’t I have figured that out before.
Actually, Users are stored in their nice Users.cs file, containing one line for each account:
Don’t you see the problem? Take a closer look. Nothing? I’d better report the signature of method that is responsible of the user creation in the
UserInfo AddUser(string username, string password, string email,
bool active, bool admin)
Do you see it now? The method needs the clear-text password, but only the MD5 Hash of the password is available (stored). Therefore Users cannot be moved. Unless the
IUsersStorageProvider is forced to use MD5 Hash values instead of passwords, which is definitely a big no-no in this kind of architecture (it would prevent from interacting with any preexistent system, and anyway stuck the data to a predefined, unchangeable format forever).
So, the only thing we can do is to use a hack in our SQL Server and MySQL Providers: they could use the same MD5 Hash for storing passwords, and if the aforementioned method is invoked with a special tag in the password parameter (say
##MD5PWD##), then it would be treated directly as a Hash instead of a clear-text password. Obviously, the code that actually moves the data should implement some dedicated logic to discern the two cases. This would mean that you could move Users only to and from “our” providers, but in general you could not move them.
I’m sure this is not a nice way to implement things, so I guess we won’t implement it. We should have thought about this before (about six months ago), but now it’s late. What do you think?