Support/Live Chat/SUMO login

From MozillaWiki
Jump to navigation Jump to 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?)

Overview

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 ######)

Timeline

  • 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.