534347 - Create a live chat migration page to merge existing SUMO and/or OpenFire accounts (tiki-livechat_migration.php)

Status: VERIFIED FIXED

(support.mozilla.org Graveyard :: Chat, defect, P2)

Description

[Paul Craciunoiu [:paulc]]

This bug covers the creation of a migration page. More information on the wiki:
https://wiki.mozilla.org/Support/Live_Chat/SUMO_login

Comment 1

[Paul Craciunoiu [:paulc]]

If the user only has a Live Chat account, I'm thinking we should simply ask them to register a TikiWiki account and then merge the Live Chat one into it.

Comment 2

[Paul Craciunoiu [:paulc]]

After talking to James, I'm integrating the registration process into the migration script as tiki-register_livechat.php, and we can just remove these files when we end this migration process.

Comment 3

[Paul Craciunoiu [:paulc]]

Attachment: v1

Functionality:
See: https://wiki.mozilla.org/Support/Live_Chat/SUMO_login#tiki-livechat_migration.php_.28bug_534347.29
* tiki-livechat_migration.php -- three starting points as per the wiki:
* tiki-register_livechat.php handles creation of TikiWiki accounts (for option 2)

To test this, define the following in webroot/db/local.php:
$host_of = "localhost";
$user_of = "openfiredb_user";
$pass_of = "openfiredb_pass
$dbs_of = "openfiredb_name";

If you need any other clarifications, let me know.

Comment 4

[Paul Craciunoiu [:paulc]]

A quick note about tiki-register_livechat.php -- it's mostly a copy of tiki-register.php, so you can do a diff to see what's changed and focus on that.

Comment 5

[James Socol [:jsocol, :james]]

Comment on attachment 418307 [details] [diff] [review]
v1

Right off the bat, this didn't work for me when I went to tiki-livechat_migration.php and chose "TikiWiki only". I got an error: "Error querying the TikiWiki database."

tiki-livechat_migration.php:

My two biggest concerns here are (1) that passwords are only conditionally encrypted, when they're always encrypted in the database--lines 30,38--and (2) the way the database connections are managed.

Even without using a more advanced library like MySQLi, this is not the correct way to handle multiple connections. The second argument to mysql_query() is a result returned from mysql_connect(). [1] That allows you to open multiple connections and run queries on each specifically. mysql_select_db() only needs to run once on each connection. (Well, it could run more than once if you were switching databases on that connection.)

The reason this would work at all is the fallback behavior of mysql_query(), which is, when a link resource is not provided, to use the last-opened link.

I appreciate the idea of using check_result() to eliminate code copy/paste, but perhaps a better method is to wrap the whole thing in a try{} block, and throw some generic exceptions to an error-handling catch{}. Using check_result() as you've defined it makes debugging very hard, since there's no way to tell _why_ the query failed. Yes, saying "if(false===$result) throw Exception('message');" all the time feels a little repetitive, but the benefit for repeating that much is specific, useful error messages.

[Nit-picking: And in general, as a personal preference, instead of checking for login = $user AND hash = $hash, I prefer to select the hash out of the database and do the comparison in the code. You get to (a) know whether it was a bad user or bad password (though you shouldn't expose that to the user) and (b) there are fewer opportunities to allow a SQL injection vector.]

I'll be happy to walk you through better ways to manage database connections and clean some of this up.

livechat_migration.js/tiki-livechat_migration.tpl

The JS should probably be done with simple $.show() and $.hide(), instead of moving HTML around all the time. 

We could probably add the JS to minify, as well as the CSS. Might as well.

[1] http://us3.php.net/mysql_query

Comment 6

[Paul Craciunoiu [:paulc]]

Attachment: v2, using pdo and exceptions

v2: now with bonus nitpick fixes!

Comment 7

[James Socol [:jsocol, :james]]

The only case that didn't work was the Livechat-only user.

After being asked to revalidate my e-mail address, I was redirected to tiki-livechat_register.php, which was an error, and the user was not added to the users_users table.

Paul, can you reproduce this?

Comment 8

[Paul Craciunoiu [:paulc]]

I couldn't reproduce. I may have missed something, though. Here are my steps:

1. On tiki-livechat_migration.php, select "Live Chat only". Enter credentials.
2. After being redirected to tiki-register_livechat.php, the user is filled in, along with the email. Fill out the rest of the information (Note: I didn't change the email).

Results:
After hitting submit, I am taken back to tiki-livechat_migration.php with the success message shown. I can then log in with the credentials I chose on the registration page, and the live chat account is deleted from the ofUser table.

My test data:
Live Chat ID: philipp123
Live Chat email: [e-mail]

Comment 9

[James Socol [:jsocol, :james]]

Comment on attachment 421528 [details] [diff] [review]
v2, using pdo and exceptions

Ok, tested all combinations. Worked for me this time, not sure what the deal was before. (This is a nice, fresh database, host, install, etc, maybe that has something to do with it?)

Comment 10

[Paul Craciunoiu [:paulc]]

r60146
Woot! Now we just need QA to try and break it :)

Comment 11

[Vishal Kamdar [:vish_moz]]

Verified, FIXED