Support/Live Chat/SUMO login

From MozillaWiki
Jump to: navigation, search

Openfire should be able to authenticate users with TikiWiki login information, when no Openfire account exists. Additionally, there needs to be a mechanism for existing Openfire accounts to be merged with a SUMO account.

Step 1: determine requirements and draft implementation plan

Partial list of topics to discuss:

  • How sumo should expose login details (a php script, direct DB access)
  • How access to the php script should be controlled (key file, restrict IP, etc)
  • Which data is necessary to provide to Openfire after authentication
    • display name
    • locale
    • avatar
    • group(s), for controlling access
  • How to handle/merge duplicate accounts
  • Who can implement what
  • What timeframe can we do it in (can we add it to 1.5?)


To provide the best security, Openfire should access the users_users table directly. TikiWiki will assign a new Live Chat ID (without spaces or punctuation) to newly created SUMO users, while existing users of either Live Chat or SUMO will have to merge their accounts.

  • Openfire will need read-only access to TikiWiki DB, and TikiWiki will need read-only access to Openfire DB.
  • DB Configuration for both Openfire and TikiWiki will need to be extended
    • IT: should Openfire and TikiWiki use a separate host/username/password for each database?

Implementation plan for Openfire (Matthew)

Implement an Openfire AuthProvider (bug ######)

This will layer TikiWiki authentication on top of native authentication.

Direct unmigrated users to migration page and refuse login (bug ######)

  • Old SUMO accounts won't have a livechat_id in the users_users table, so they will need to create one on tiki-livechat_migration.php
  • Old Live Chat accounts will need to be migrated into a SUMO account

Automatically add users to Openfire groups based on TikiWiki group membership.(bug ######)

  • Room monitors, support team, etc

Implementation plan for TikiWiki (James and/or Paul)

Database (bug 534340)

bug 534340 (same as tiki-register.php)

  • Add livechat_id to users_users table.
    • NULL for existing users
    • A stripped version of the username for new accounts, if available
    • The old Openfire username for migrated accounts
  • Make sure tiki-register.php and tiki-livechat_migration.php can access Openfire's database.

tiki-register.php (bug 534340)

bug 534340

  • A livechat_id must be generated for each new user. Must be unique both among other livechat_id's and existing users in Openfire's of_users table

tiki-livechat_migration.php (bug 534347)

bug 534347

  1. Ask users if they have a Live Chat account and/or a TikiWiki account
    • Both: Ask for both usernames and passwords. The livechat_id in the TikiWiki account should be set to the existing Openfire ID.
    • Openfire only: Ask for the Live Chat password, then create a new TikiWiki account with the same credentials if possible. (If the TikiWiki username is taken, ask the user to pick another)
    • SUMO only: Ask the user to log in, then create a livechat_id for the user. (Use the SUMO username if available, otherwise ask the user to create one)
  2. After the livechat_id is determined, delete the existing Openfire account if applicable. (Will require read-write access to Openfire DB)
  3. Direct the user to sign into Live Chat using the TikiWiki username and password. The livechat_id will be used for generating a Jabber ID, which has different requirements from the user name.

Cleanup and fixes

  • Create a Live Chat Room Monitor group on TikiWiki
  • Add live chat ID management to tiki-adminusers.php (bug 534350)
  • Create a temporary script to automatically merge all TikiWiki and Openfire accounts where usernames and passwords exactly match. (bug 534351)
  • After 6 months, purge unmigrated Live Chat accounts. (Matthew)
  • Turn off migration feature after 6 months, when all unmigrated Openfire accounts are deleted. (bug ######)


  • Implement Openfire support in 2009Q4, but wait to deploy it until TikiWiki support is done.
    • Set this up on a testing server so that TikiWiki patches can be tested. Should be done before work on TikiWiki begins.
  • Schedule TikiWiki support for the next minor release after 1.5. Target for early 2010Q1.