534340 - Generate livechat_id when user registers (at tiki-register.php)

Status: VERIFIED FIXED

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

Description

[Paul Craciunoiu [:paulc]]

https://wiki.mozilla.org/Support/Live_Chat/SUMO_login
Part of adding SUMO logins to livechat. See above wiki page for more details.

Comment 1

[Paul Craciunoiu [:paulc]]

Attachment: update tiki-register and userslib

This patch does the stuff mentioned on the wiki:
https://wiki.mozilla.org/Support/Live_Chat/SUMO_login#tiki-register.php_.28bug_534340.29
If livechat_id already exists, the response is as if username must be changed. Seems reasonable?

Comment 2

[Paul Craciunoiu [:paulc]]

Attachment: SQL to create livechat_id column

Corresponding SQL to attachment 417204 [details] [diff] [review].

Comment 3

[Paul Craciunoiu [:paulc]]

Question regarding: https://wiki.mozilla.org/Support/Live_Chat/SUMO_login#Database_.28bug_534340.29
It seems to me that tiki-register.php does NOT need access to the OpenFire database, since it creates a unique livechat_id based a the newly registered user login. I'm not sure it would be necessary to check the OpenFire database (what would we look for? potential future migrators?). Am I missing something?

Comment 4

[Matthew Middleton (:zzxc)]

The livechat_id must be unique both on itself and on Openfire's of_user database, to avoid duplicate Openfire account names.  This purpose is only temporary, as no Openfire accounts will exist after the migration.

It may be better to create temporary TikiWiki accounts for all Openfire accounts with name collisions in the automatic migration script, to avoid additional complexity here.  (Openfire accounts without name collisions will be converted automatically.)

Comment 5

[Paul Craciunoiu [:paulc]]

(In reply to comment #4)
So from what I understand, you want to make sure that no two users can be online where one's SUMO livechat_id == the other's Openfire user. Is that right? If so, you can avoid this by appending _of (after sign-in) for Openfire users, and additionally giving users a choice between signing in with Openfire accounts or SUMO livechat IDs (which I'm assuming you are doing anyway, while we are in this migration process). Would this work?

So it looks like we should merge non-conflicting Openfire accounts first (bug 534351).

Additionally, we can add a temporary notification at the top of tiki-register.php: "Already have an Openfire account? Transfer it over using the <link>migration process</link>".

This should be enough, right? Sounds good Matthew?

Comment 6

[Matthew Middleton (:zzxc)]

(In reply to comment #5)
> (In reply to comment #4)
> So from what I understand, you want to make sure that no two users can be
> online where one's SUMO livechat_id == the other's Openfire user. Is that
> right? If so, you can avoid this by appending _of (after sign-in) for Openfire
> users, and additionally giving users a choice between signing in with Openfire
> accounts or SUMO livechat IDs (which I'm assuming you are doing anyway, while
> we are in this migration process). Would this work?

Users won't be given a choice as to which authentication system to use.  Openfire will first check the SUMO database for a valid sign-on.  If this login fails, the server will try Openfire's of_user table.  If both fail, the user will see an authentication failed dialog.

> So it looks like we should merge non-conflicting Openfire accounts first (bug
> 534351).

Yes, this must be done first before SUMO logins will be active.

> Additionally, we can add a temporary notification at the top of
> tiki-register.php: "Already have an Openfire account? Transfer it over using
> the <link>migration process</link>".
> 
> This should be enough, right? Sounds good Matthew?

Yes, linking to that page from tiki-register sounds like a good idea.  Openfire will also send a notice to users who authenticate from the of_users table that they should migrate.

Comment 7

[Paul Craciunoiu [:paulc]]

I still would rather have the Openfire sign-in process handle uniques between the two databases and let users pick, rather than temporarily bloat tiki-register.php.

What do you think James?

Comment 8

[Paul Craciunoiu [:paulc]]

(In reply to comment #7)
> I still would rather have the Openfire sign-in process handle uniques between
> the two databases and let users pick, rather than temporarily bloat
> tiki-register.php.
So if I understand it correctly, this is not a concern anymore. We run the automatic migration script first to help minimize potential conflicts (bug 534351) and if any problems arise with users taking someone else's preferred ID, we can handle them on a case-by-case basis using the admin interface (bug 534350). Hence the patch above should suffice (functionally...) and only the SUMO db needs to be checked against for livechat_id uniqueness.

If I hear no objections I'm going to assume this way is fine.

Comment 9

[Matthew Middleton (:zzxc)]

Openfire will consult the SUMO database first for a valid sign-in, so any conflicts generated would allow an Openfire account to be taken over.

The best way to work around this is probably to have the Openfire plugin compare the creation date of the TikiWiki account to the Openfire account.  If the TikiWiki account is newer and a matching Openfire account exists, then TikiWiki authentication should be skipped.  What do you think?

Comment 10

[Paul Craciunoiu [:paulc]]

That sounds good! One exception is when the TikiWiki account has been created by the migration script. So I guess you will need a way to distinguish between the two cases -- what if the migration script copies over the creationDate from Openfire (ofUser table)?

Comment 11

[Matthew Middleton (:zzxc)]

(In reply to comment #10)
> That sounds good! One exception is when the TikiWiki account has been created
> by the migration script. So I guess you will need a way to distinguish between
> the two cases -- what if the migration script copies over the creationDate from
> Openfire (ofUser table)?

The migration script will delete the user from the ofUser table, so this won't be an issue.

Comment 12

[Paul Craciunoiu [:paulc]]

Oops. Right :)

Comment 13

[James Socol [:jsocol, :james]]

Comment on attachment 417205 [details] [diff] [review]
SQL to create livechat_id column

WFM.

Comment 14

[James Socol [:jsocol, :james]]

Comment on attachment 417204 [details] [diff] [review]
update tiki-register and userslib

Could you change the mb_ereg_replace to have a + operator on it? I'd rather "user%#$name" => "user_name" than to "user___name". Or is that going to cause problems with the uniqueness?

Comment 15

[Paul Craciunoiu [:paulc]]

Attachment: v2, turns all invalid characters into one underscore

Tharrrrr she goes...

Comment 16

[Paul Craciunoiu [:paulc]]

(In reply to comment #15)
> Created an attachment (id=418286) [details]
> v2, turns all invalid characters into one underscore
We decided that conflicts are not that much more likely so doing this is okay.

Comment 17

[James Socol [:jsocol, :james]]

Comment on attachment 418286 [details] [diff] [review]
v2, turns all invalid characters into one underscore

Working for me. Matthew, this meets the requirements?

Comment 18

[Paul Craciunoiu [:paulc]]

According to Matthew, validation should follow these specs: http://xmpp.org/rfcs/rfc3920.html#nodeprep

Comment 19

[Paul Craciunoiu [:paulc]]

r58192 (trunk). Will we need this on fennec in case they use live chat before we do the merge back to trunk?

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on trunk; Vishal and I actually verified this when we found that our new accounts let us log in :-)