687500 - Affiliates: add browserID capability to application

Status: VERIFIED FIXED

(Firefox Affiliates Graveyard :: affiliates.mozilla.org, defect)

Description

[Chris More [:cmore]]

Per this wiki page:

https://wiki.mozilla.org/Identity/BrowserID/MozillaDogfood

We should add BrowserID to a post 1.0 version of the Affiliates application.

Comment 1

[Austin King [:ozten]]

Attachment: Affiliates Homeage v0

Homepage Login becomes drastically simpler and Registration becomes somewhat simpler.

Login with a known email address goes to Affiliates_Register_Success.png
Registration goes to Affiliates_Register_Success.png
Login with an unknown email address goes to Affiliates_Login_Unknown.png

Comment 2

[Austin King [:ozten]]

Attachment: Affiliates Registration Success v0

No change from production. Adding for reference.

Comment 3

[Austin King [:ozten]]

Attachment: Affiliates Login Unknown v0

This covers two corner cases:
1) New user clicks Login
2) Existing user chooses wrong email address in BrowserID

Comment 4

[Austin King [:ozten]]

(In reply to Austin King [:ozten] from comment #3)

Three notes:
a) [e-mail] and the password being pre-filled is my browser being weird. I meant to clear that out before taking a screenshot
b) The title could be 'New User Profile' instead of 'Edit your user profile' to emphasis this is a new account.
c) hamsterdance is my real name

Comment 5

[Austin King [:ozten]]

I'm open to any help, but Comments #1 - #4 are mainly to get feedback on two aspects.

Changing 'Log In' button from white to blue.

Any graphic <3 for the "Already have a profile" warning sidebar.

Comment 6

[Austin King [:ozten]]

The main code is ready for review at
https://github.com/mozilla/affiliates/pull/64

Two issues I didn't anticipate 
* unit tests
* Django admin authentication

I'm requesting a code review and discussion while I tackle these other issues.

Comment 7

[Austin King [:ozten]]

(In reply to Austin King [:ozten] from comment #6)

I'm removing irrelevant unit tests and repairing broken once with mock BrowserID responses.

In terms of  Django admin authentication...

Plan - Normal users have no usable password. If the user is_staff or is_superuser, then on the profile page, we show a change password section.

To become an admin user, you need someone to use the admin panel and give you permission, then you'd set a password. The first user can be created via a django manager command.

How does this plan sound?

Comment 8

[Osmose [:osmose, :mkelly]]

I like this plan. We don't currently use individual admin accounts, but that may change in the future as we add more and more banners.

Comment 9

[Austin King [:ozten]]

(In reply to Michael Kelly [:mkelly] from comment #8)

Okay, I'm code complete and ready for 2nd code review on the same pull request:
https://github.com/mozilla/affiliates/pull/64#commits-pushed-d299cf6

Comment 10

[Crystal Beasley [:skinny, :crystal]]

Is this on staging? I'd love to have a look?

Comment 11

[Osmose [:osmose, :mkelly]]

(In reply to Crystal Beasley [:skinny, :crystal] from comment #10)
> Is this on staging? I'd love to have a look?

Not yet. After it's reviewed and we merge it it'll be on dev and I'll post a link in this bug.

Comment 12

[Austin King [:ozten]]

The reason I went registration form > BID flow instead of BID flow > registration form like current Mozillians:
* We collect 1 piece of information (display name) plus TOS
* Next step is into affiliates badge creation (which is the point of the site)
* Profile information is optional and not part of average user's registration flow
* Switching to profile oriented second step makes it less quick to start creating affiliate badges. Having only display name and TOS seemed weird after BID flow.
* Error in flows and loss of registration form data isn't very painful (compared to Mozillians)
* Reusing existing visual design

Looking forward to your input.

Comment 13

[Austin King [:ozten]]

I don't see an ETA on the staging server bug, so I've upload a screencast of 4 possible login flows.

http://youtu.be/a4aMJyM2ASs

Comment 14

[Ben Adida [:benadida]]

mkelly, cmore: can we move on pushing this to stage? This seems quite ready, and it would be a shame to start pushing this into December when everyone is going to get swamped trying to wrap up quarterly goals. Early win here, I think.

Comment 15

[Osmose [:osmose, :mkelly]]

Ben: I'll be meeting with UX tomorrow about this, and once the changes for that go in we can send this off to l10n and security for review. Hopefully we can push this out within a few weeks.

Comment 16

[Ben Adida [:benadida]]

mkelly: I'm pretty sure that's not what we had agreed on a few days ago: that this would go in now. Let's talk about this urgently, as this means missing a quarterly goal that we had all agreed would be done.

Comment 17

[Crystal Beasley [:skinny, :crystal]]

Here's the mockup. 

http://cl.ly/1S3M203O331y3i1D1e25

Comment 18

[Austin King [:ozten]]

(In reply to Crystal Beasley [:skinny, :crystal] from comment #17)

I'm assuming you don't want password fields added back in :)

Why do we want the user to type their email, when the clicking Register will get a verified email?

Can we base the UX feedback on the work that is already complete? I'm happy to change login to the BrowserID button. Where does the 'easier way to sign up' link go?

Milos of l10n has asked that we use the same string across Mozillians and Affiliates. If we're adding "BrowserID is an _easier way to signup_." then shouldn't we reuse the analygous string for Mozillians "_What is BrowserID? Why are we using it?_"

Comment 19

[Crystal Beasley [:skinny, :crystal]]

I walked through it with ozten and I'm good with it as he has it. When the browserID branding comes through we'll revise with their standard sign in button.

Comment 20

[Osmose [:osmose, :mkelly]]

We've decided

Comment 21

[Ben Adida [:benadida]]

woohoo, is there a dev server we can check out?

Comment 22

[Osmose [:osmose, :mkelly]]

It's up at https://affiliates-dev.allizom.org/en-US/ , but BrowserID's SSL certificate isn't being accepted by the server. Bug 710444 and bug 710441 are blockers for this to work on affiliates-dev (bug 706633 is the bug for the en-US release).

Comment 23

[Osmose [:osmose, :mkelly]]

Marking this as resolved; this was pushed to en-US a while back.

Comment 24

[Matt Brandt [:mbrandt]]

QA verified .. bid goodness landed and is the auth mechanism for the site