314928 - Need accessory auth tools for users

Status: VERIFIED FIXED

(Webtools Graveyard :: Litmus, defect)

Description

[Chris Cooper [:coop] (he/him)]

There is currently no authentication in Litmus. We accept the first email address the user provides when testing, use this to build a cookie, and then never let them change it (without removing the cookie, of course). We need to implement proper authentication:

* mirror existing Bugzilla login information. This should be synced at some regular interval;
* allow users to login/logout from within Litmus;
* auto-populate all email fields with current credentials from cookie when present;
* redirect through login screen when login credentials are not present;
* redirect users without Bugzilla accounts to Bugzilla.

Comment 1

[Chris Cooper [:coop] (he/him)]

We've decided that mirroring the Bugzilla auth info isn't a good way to go, so I've updated the summary to reflect that. 

For one, we think that requiring that testers have an existing Bugzilla account is too much to expect of testers, especially for casual testers. The hope is that as users become more comfortable with testing, they will naturally migrate to using Bugzilla on their own. We can try to encourage this behavior as much as possible during our testdays.

Also, importing Bugzilla authentication information raises several technical challenges that, while not insurmountable, add extra levels of complexity that aren't necessary. We would need to keep the Litmus copy of the Bugzilla auth information in sync with the information in Bugzilla. This would mean that testers who signed up in Bugzilla would not be able to test immediately. There are also (currently) many more users in Bugzilla than in Litmus. The user list alone would grow the Litmus database considerably without any guarantee that any of those users would ever test using Litmus. Perhaps the most important factor however is security. We instantly become responsible for protecting a copy of one of the most important user resources in the Mozilla community. Not that we plan on _not_ protecting Litmus auth system (whatever form it might take), but breaching the Litmus system would compromise two systems if we were to use the Bugzilla auth info.

This has some implications as to how we do end up implementing auth in Litmus. I'll document my thoughts on that here shortly.

Comment 2

[Chris Cooper [:coop] (he/him)]

What we need to track:

* email address: Not visible by the community in general, only by admins. In order to have at least some relation to Bugzilla, we should ask that that users who sign up to test use the same address as for their bugmail.

* nickname for display: This will be the name attached to Litmus results that the community will be able to see. For convenience, we will ask that this be the same as the IRC nick they will use when connecting to #testday.

* Real name: not strictly necessary;

* password

* trust level: we need some indication of the level of confidence we have in the results submitted by a given tester. Known "good" testers can have this level set initially to a higher level, but new testers will need to gain trust through result submission. Can-o'-worms potential here unless we stay on top of this on the admin-side. We'll need to be responsive to community members who feel slighted.

* is_admin: Yes or No

What this implies functionality-wise:

* login/logout pages

* user info admin pages: both for admins and the users themselves

* lost password retrieval/reset functionality

* update current cookie code to use new auth info. Security audit for this code would not be amiss either.

This authentication problem has been solved many times in the history of the web, and we really shouldn't be reinventing this wheel. 

Zach: can you try to track down an existing solution that will play nicely with the existing setup? (MySQL-based, template-aware) If you can't find something appropriate, we'll consider our options.

Comment 3

[Zach Lipton [:zach]]

This has landed (minus Bugzilla auth pending some issues related to the changing Bugzilla schema and the development of an API) and will be going live on the production installation. Any further work can be handed by follow-up bugs.

Comment 4

[Chris Cooper [:coop] (he/him)]

There are some pretty serious issues I'm in the process of fixing.

Comment 5

[Chris Cooper [:coop] (he/him)]

The core authentication component is now in place, and I've even added the ability to login directly from the sidebar without needing to go through the run tests process.

What we still need are some basic tools for to see and edit their personal information, things like:

* update email address;
* change password;
* retrieve a lost password;
* view personal testing stats.

The user 

Comment 6

[Chris Cooper [:coop] (he/him)]

(Last comment got truncated)

I was thinking the user could click on their nickname in the sidebar to access their profile and then make any changes from there.

Comment 7

[Zach Lipton [:zach]]

Yeah, the user preferences interface needs to happen. I'll put something together for that. The retrieve a lost password function is going to require sending emails to users to prevent abuse; we should figure out how exactly that's going to work. 

I'd also like to see the Bugzilla login integration actually happen now. I've begun fixing the code-level issues with that feature and will talk to sysadmins@m.o about arranging read-only access to Bugzilla user table for Litmus once that is done.

Comment 8

[Chris Cooper [:coop] (he/him)]

The user profile access portion of this has been taken care of as part of bug 328489, but we still need the lost password/mail interface. Again, we can probably crib something from Bugzilla here.

Comment 9

[Marcia Knous [:marcia]]

a user forgot his password and could not reset it. When I tried to do so through the manage users interface, he still could not login, despite the PW was plain text. It would be nice to see this implemented sooner rather than later, or at least have us be able to reset passwords for users that forget them.

Comment 10

[Zach Lipton [:zach]]

You should definitely be able to change the user's password using the edit users interface. I just tested changing a password on my staging install and it worked properly. You should be able to go into edit users, search for the user account, and type a new password into the password field. Unfortunately, there is no way right now for the user to change this assigned password to something new, but this is something I would like to add in the near future.

We do not currently have a way for users to reset their own password, but that is a planned feature. Do you still have the user's email address? Posting it publically here probably isn't the best of ideas, but if you want to email it, I can take a look and see what's going on with their account. 

Comment 11

[Zach Lipton [:zach]]

I think this is pretty much complete now with coop's user settings changes. Users can change their passwords, real names, and irc nicknames. Are there any other user preference type tools we need at this time?

Comment 12

[Chris Cooper [:coop] (he/him)]

(In reply to comment #11)
> I think this is pretty much complete now with coop's user settings changes.
> Users can change their passwords, real names, and irc nicknames. Are there any
> other user preference type tools we need at this time?
> 

The standout missing feature is still the automated password reset for users. Unless we're happy fielding all these requests via direct contact (IRC or email), we will need this some way to to this. Users may well lose their interest in testing if they have to wait for us to respond to these kinds of requests though.

Comment 14

[Zach Lipton [:zach]]

Fix checked in and the public install was updated last night with no reported negative feedback. Users can reset their password from the Login page, with email authentication of user account ownership.