September 4, 2016 in Technical Problems
My holiday blog is built on Joomla. (Greetings from Korčula, an island off the coast of Croatia, by the way!) I'd like to make life easier for my wife by converting it to IPS4 instead.
In itself, this isn't a bad project for me to learn from. I know what I want the theme to look like, I know the Joomla database, I know which articles I'd like to move into Pages, and so on.
The one thing that I'm not sure about, though, is how one recreates users in a conversion, maintaining the original credentials. For good reason, I can't go into the Joomla database and see what each user's password is. Everything is hashed, just as it is on IPS4.
In Joomla I have the following structure:
`id`, `name`, `username`, `email`, `password`, ...
`member_id` mediumint(8) NOT NULL AUTO_INCREMENT,
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`member_group_id` smallint(3) NOT NULL DEFAULT '0',
`email` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`members_pass_hash` varchar(60) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`members_pass_salt` varchar(22) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
So, already I have the problem that in Joomla there is just a single field related to passwords in the database, whereas in IPS4 there are two - the hash and the salt.
What's the best way to tackle something like this? OK, I know what my own credentials are and I could get my wife to register on the IPS4 version and then attribute the various posts to her member_id afterwards, but that's not the point. I'm curious about the general principle of how one goes about converting members from one site to IPS4 whilst still maintaining those users' credentials.
First you should install the default IPS4 Converters.
The approach to do this will be different depending upon whether the password is able to be converted or not.
In most circumstances you'll have to create a custom login handler and passwords will not be able to be converted in the conversion process. The principle to follow is to convert the password on first login, rather than as a part of the conversion itself. This is because on login you will have access to the plain text version of the password (because that is coming from the login form). So if that plain text is able to be converted to the same hash that Joomla had stored in its database, you can use that incoming plain text to create the IPS 4 equivalent of the password.
In that case your conversion should just move the password field to a column named conv_password on the core_members-table for that member. You should also have a column named conv_password_extra, but in this case it sounds like it will be unused. Both of these columns are added by the converters application.
Your custom login handler should preferably be "behind" the default login handler in the "login queue". Meaning that when authentication with the default login handler fails, it will move on to the next active login handler to see if it will be able to login with that. In your custom login handler you then convert the plain text you receive from the password input on the login form to a value that is able to be matched against the value stored in conv_password. This is the part where you will need to know how this is done in Joomla.
Let's say for a silly example that Joomla passwords are simply the password + the string joomla applied to it, that is md5-hashed. Your code inside the login handler then would be something along the lines of:
if ( $member->conv_passord === md5($inputPassword . 'joomla') )
$member->conv_password = NULL;
$member->conv_password_extra = NULL;
$member->members_pass_salt = $member->generateSalt();
$member->members_pass_hash = $member->encryptedPassword( $inputPassword );
If we see that the input password from the login form + the string joomla that is md5-hashed, matches with the hash stored in the column conv_password, then we have a successful login.
When we have a successful login we can toss away any values in conv_password and conv_password_extra (set them to NULL) because at that point we can use the input string from the login form to create our proper IPS 4 login credentials for use in future logins. Which is what you can also see done here. On any future logins that member will then be handled by the default login handler.
Look at how it's handled in the various converters and the converter login handler that IPS has to deal with this.
In some rare cases you'll be able to convert the passwords already in the conversion process, for example if passwords have been stored as plaintext in the other database.
This topic is now archived and is closed to further replies.
Started 1 hour ago
Started 2 hours ago
Happy go Lucky
Started 3 hours ago