From MozillaWiki
Jump to: navigation, search

« back to Litmus main page

Initial Thoughts (coop)

We have to allow for anonymous testing, i.e. we cannot require a Bugzilla account for Litmus use. The perception is that this is too high a barrier to entry for casual testers.

Suggestions to overcome this:

  • straight anonymous testing
  • password-based logins with no relation to Bugzilla (con: another account for users to remember/forget)
  • redirect users through Bugzilla on result submission
  • ability to associate results with a Bugzilla/Litmus account after the fact.
    • track some form of data about the user in the db (temp username, cookie) and backfill that once the user signs up with an account.

NOTE: these are not necessarily competing paradigms; we might adopt more than one

Bug 314928


The Litmus Authentication System is designed to accomplish several goals:

  • Manage user data related to testcase management, including information about the authors of testcases and test results.
  • Utilize the existing authentication information maintained in the Bugzilla user table so that contributors that already hold Bugzilla accounts do not need a separate account to use Litmus.
  • Allow more casual testers to contribute without the burden of creating a Bugzilla account.
  • Users who begin without a Bugzilla account should be able to later "graduate" and link their Litmus account with their Bugzilla account.
  • Maintain security and privacy of user data, including email addresses, such that users are comfortable giving out any personal information used to participate in Mozilla QA.

Initial Features

  • Login
  • Create account (Litmus-only or linked with Bugzilla)
  • New login cookie for user state (with code-level security audit to follow)


  • What (if anything) should users be able to do anonymously?
    • One idea: allow result submission with only an email address, but encourage them to make an account as they keep submitting more and more results. Track remote IP address so we can ban abusers as needed.
    • Require a Litmus account (easy to create with just email and password) for submission, allow the user to later link that with a Bugzilla account if they end up creating one.
      • This is probably our best option, since it would also keep it possible to use Litmus separately from Bugzilla as needed.
    • Require a Bugzilla account for all result submission.
      • Not really a good option, as creating a Bugzilla account is entirely too much trouble.


A collection of privacy rules or settings is required to govern when email addresses and other personally identifiable information is displayed. In general, we should tend toward not displaying information about casual testers/result submitters while displaying information about test authors and community leaders. In some cases, it may be more appropriate to display a real name only, but careful consideration should be given to avoiding user spoofing attacks since real names cannot be guaranteed to be unique.

Why not an existing solution?

While the CPAN has several resources for pre-built authentication systems for web applications, I (Zach) believe that the need for integration with Bugzilla's authentication table (but not the wholesale copying of the Bugzilla user database) is great. We certainly should not require casual testers to create Bugzilla accounts in order to contribute, but for those with accounts, having only one account offers distinct advantages.

Proposed User Table

password (crypt'd)
(various preferences TBD)

Proposed Session Table

session_id (secure random token stored in login cookie)

Integration with Existing Systems

The Litmus authentication system is designed to link with other sources of user information. Currently (well, in the extremely near future), Bugzilla users can use their Bugzilla user account and password to login to Litmus. Whenever the Bugzilla user sets a new password, that new password will be used for Litmus login as well.

In addition, Litmus has support to integrate with's proposed LDAP-based central user database. When this system is developed, a user will be able to maintain only one user account for all services, including Litmus. Litmus will maintain its own user records to store preferences and privilege settings.