Closed Bug 889814 Opened 12 years ago Closed 12 years ago

Setup infrastructure for Persona authentication

Categories

(support.mozilla.org :: General, defect, P2)

Product:
support.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2013Q3

People

(Reporter: rrosario, Assigned: rehandalal+mozilla)

References

Details

(Whiteboard: u=dev c=general p=3 s=2013.14)

One of our big goals of 2013Q3 is to have Persona auth on SUMO. There are a lot of UX details to figure out especially in the AAQ flow. It would be great to start getting all the technical parts ready. * Add django-browserid to vendor. * Persona requires that email addresses be unique. ** Figure out if we are enforcing unique email addresses already. ** Figure out if there are any duplicate email addresses in our database. * Enable the app, add the js, add any required settings, ... * Put a sign in link for Persona behind a flag. * Figure out what required user fields we need to get from the user the first time they sign in. Off the top of my head, I know we need a unique username from them since we use that everywhere. * File followup bugs. Did I miss something?
MDN converted from "old-style" accounts to Persona accounts. It's definitely worth pinging them to find out: 1. the process they used to migrate 2. any problems they bumped into 3. any ui/ux problems they bumped into 4. anything else they can tell us that we're not thinking about
There is quite a bit to do here. Making this a 3pter, but we can adjust and/or file followup bugs. If followup bugs are filed, I'd vote for working on them as you file them instead of waiting for a new sprint. We'll cross that bridge when we reach it.
Whiteboard: u=dev c=general p= s=2013.14 → u=dev c=general p=3 s=2013.14
:groovecoder Can you or somebody on the mdn team comment on comment 1? Thanks!
Flags: needinfo?(lcrouch)
While we're talking about infrastructure changes, another thing you may want to consider is the ability to have multiple emails or change one's email: https://developer.mozilla.org/en-US/docs/Mozilla/Persona/The_implementor_s_guide/Enabling_users_to_change_their_email_address
I'll give some preliminary answers but I'm cc'ing :lorchard since he ninja'd BrowserID into MDN. 1. the process they used to migrate Our real migration of users was from MindTouch -> django which we did over 8-12 months and collected email addresses into the django user database. Once we had email addresses for users, the "migration" wasn't much work at all - the BrowserID assertions contain a verified email address so we can just sign the user in with it. 2. any problems they bumped into Users missing email addresses continue to bite us; that was an aspect of MindTouch though - it didn't require email addresses for users. 3. any ui/ux problems they bumped into Craig implemented a door-hanger info-box on the "Sign in" button for first-time clickers. Ben commented that it was a great UI enhancement for BrowserID. http://screencast.com/t/WkQBSHjcPcX 4. anything else they can tell us that we're not thinking about Last I heard some SUMO articles and answers instruct users to disable JavaScript to fix some issues. Persona won't work without JavaScript. But, once a user is signed-in they don't need JavaScript again unless they lose their login cookie.
Flags: needinfo?(lcrouch)
(In reply to François Marier [:francois] from comment #4) > While we're talking about infrastructure changes, another thing you may want > to consider is the ability to have multiple emails or change one's email: > > > https://developer.mozilla.org/en-US/docs/Mozilla/Persona/ > The_implementor_s_guide/Enabling_users_to_change_their_email_address MDN doesn't allow multiple emails so far, mostly just because there hasn't been a huge demand and the UI would probably be cumbersome. We do support email change, though: That's done by signing in with Persona using the current email, and then signing in again with the new email on a special page [1] for changing the email. Since both addresses were previously verified by Persona, we don't need to send out an email with a verification link. [1] https://developer.mozilla.org/en-US/users/change_email
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #0) > One of our big goals of 2013Q3 is to have Persona auth on SUMO. There are a > lot of UX details to figure out especially in the AAQ flow. > > It would be great to start getting all the technical parts ready. > > * Add django-browserid to vendor. You can look at what MDN did... But, I did it using an older version of django-browserid, and I had to gin up our own custom handlers for the verification & signin stuff. One thing we added, which I think might be part of the django-browserid package these days, was to support an interstitial "signup" page that asked for a user name. At the time, the out-of-box app would just create an account using an auto-generated username We also have a lot of cruft in there to support the migration from old-school Mindtouch accounts to new-school Django. That stuff is ugly, but can be ignored > * Persona requires that email addresses be unique. > ** Figure out if we are enforcing unique email addresses already. > ** Figure out if there are any duplicate email addresses in our database. Yup. Mindtouch was *not* enforcing unique email addresses. A survey of the database showed that duplicate addresses were mostly spammers and test accounts. I think what we eventually implemented was code that logged in the last-recently-used account matching the Persona email address. > * Enable the app, add the js, add any required settings, ... > * Put a sign in link for Persona behind a flag. > * Figure out what required user fields we need to get from the user the > first time they sign in. Off the top of my head, I know we need a unique > username from them since we use that everywhere. User name is only field we ask for, everything else is optional and can be edited later. We also had some "emergency" procedures: If the email address from Persona didn't correspond with any email address in the DB, we offered a chance to login with a password and change the email address then and there. (ie. In case the user remembered the password but forgot / lost control of the email originally used to sign up) > * File followup bugs. > > Did I miss something?
MKELLY just wrote this up: https://github.com/mozilla/django-browserid/pull/177 I haven't finished mulling it over, but at first blush it seems like AAQ might be a similar situation.
So I checked the DB (not the LATEST but fairly recent) for duplicate emails / missing emails and we have: - 4 users with missing emails. They all seem like dummy/junk/test accounts that have only logged in once (at the time they were created) - 2 emails that occur twice each. So it should be fairly easy to consolidate these two into one user account each.
Blocks: 897048
On Thursday, we pushed this to stage so it could sit a bit and we could see if errors pop up. We should probably run the QA test suite for stage--I don't know if that's been done or not, yet. Right now, I'm seeing these on stage: https://errormill.mozilla.org/support/sumo-stage/group/52900/ That means we need to do server configuration changes for all our environments to add SITE_URL. Further, I'm puzzled because I thought we landed a change in django-browserid to make that SITE_URLS (plural), but I don't see that anywhere. Anyhow, this issue is good to know when doing the bugs for the configuration changes: https://github.com/mozilla/django-browserid/issues/166 Also, richard uses django-browserid for authentication and when I was working on richard a long time ago, I got bit by lack of network connectivity preventing me from logging in. That will bite us and contributors, too. I wrote about it in this issue: https://github.com/mozilla/django-browserid/issues/140 We should spin off a new bug to account for that either with documentation or adding some infrastructure to support a "OFFLINE_OVERRIDE" mode (which is what I did with richard) or something else.
(In reply to Will Kahn-Greene [:willkg] from comment #11) > On Thursday, we pushed this to stage so it could sit a bit and we could see > if errors pop up. Uhm, I see it on master: https://github.com/mozilla/kitsune/commit/b3810eaf7f692b83f8c12d352412e1279a39209f *shakes fist at :rdalal* :) > We should probably run the QA test suite for stage--I don't know if that's > been done or not, yet. I did that and a bunch of manual testing. Things look good. > Right now, I'm seeing these on stage: > > https://errormill.mozilla.org/support/sumo-stage/group/52900/ > > That means we need to do server configuration changes for all our > environments to add SITE_URL. Good news is that that's a URL specific for browser id that was getting hit by a whitehat script. It isn't going to get hit by users while the flag is off. > We should spin off a new bug to account for that either with documentation > or adding some infrastructure to support a "OFFLINE_OVERRIDE" mode (which is > what I did with richard) or something else. Oy. I hadn't thought about this. Good to know.
My vote is to push this on to prod and leave it off everywhere until we get WebOps to update SITE_URL setting in settings_local.py. Or can we do something like this in settings.py: SITE_URL ( 'https://support-dev.allizom.org', 'https://support.allizom.org', 'https://support.mozilla.org', ) Would that be bad?
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #13) > My vote is to push this on to prod and leave it off everywhere until we get > WebOps to update SITE_URL setting in settings_local.py. Or can we do > something like this in settings.py: > > SITE_URL ( > 'https://support-dev.allizom.org', > 'https://support.allizom.org', > 'https://support.mozilla.org', > ) > > Would that be bad? That seems fine to me, but it's definitely SUMO-specific and not Kitsune-general. Beyond that, I don't know what's good/bad anymore.
I did this for now: https://github.com/mozilla/kitsune/commit/f78b33590274c08ad217703c65fa0b30b9680d03 And deployed it all to prod \o/.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.