714934 - add support for browserid/persona authentication

Status: RESOLVED WONTFIX

(support.mozilla.org :: Users and Groups, task)

Description

[Vito Smolej]

No need for details, I hope;)

regards

smo

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

I just chatted with some sumo folks about browserid and here's my take on our take:

1. we want to add support for browserid if only because other Mozilla properties are doing it

2. browserid isn't fully localized currently (that will change over time)

3. browserid doesn't currently add much value to the SUMO userbase (that might change over time)

4. because of numbers 2 and 3, we'd want to add browserid authentication to our existing authentication--not switch SUMO to be browserid-only (this may change in the far future)

5. because of number 4, we'd want a login page that supported both the username/password and browserid authentication methods

6. we're concerned that number 5 might be confusing for users, so the UX needs to be crystal (ha!) clear and not confusing

7. if at some point in the future we wanted to add API bits that require authentication, we should look at OAuth for API authentication--we wouldn't use browserid


Does that cover everything?

Putting this in the 2012q1 milestone to look at for q1.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Another possible reason we probably can't go browserid-only is that we need to support users on screwy old browsers. We'd have to make sure that browserid works on those browsers before switching. (This is off the top of my head--someone would need to check this out before we assert it's a fact.)

If it's true that browserid doesn't work for all the browsers we support, we might want to hide the browserid authentication button on the login page for browsers that don't support it.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

James pointed out that in SUMO we sometimes tell people to disable javascript as a trouble-shooting measure. Given that browserid is javascript-only, this requires us to maintain a secondary login system. At that point the ux/ui gets complicated.

Quotes from the email exchange:

Ben: I don't think we can do much on this soon, it's mostly a corner case right now. Could you, on SUMO, say that JavaScript is required for logging in?

James: No. SUMO is about troubleshooting. Steps like "Disable JavaScript" and "Do something then restart and come back" have to be followable. If this is a corner case, then SUMO will need to continue to support multiple login paths for the forseeable future. (Or not support BrowserID yet.)

Austin: So there is a hard use case that the user must be able to login in to
SUMO for personalized content while JavaScript is disabled?

If so, this is an understandable reason to force a fallback login. Or
could the user still access the help page they were on, since it's a
help screen available to an anonymous visitor.?

James: You can read help content but you can't ask questions or respond to answers. With the users we are regularly dealing with "oh let me just turn JavaScript back on to log back in to answer" is not something we should expect to occur to them.

I'm concerned that maintaining multiple login paths in such a way that users might have to pass through both is not a good user experience. Particularly that it violates both ux-consistency and ux-implementation-level (BID is implemented in JS, thus the login workflow breaking with JS surfaces implementation details) and kinda-sorta ux-mode-error.


Given that, it seems like it makes sense to push off browserid implementation until there's a better javascript-less story or the ux/ui for multiple login methods is figured out.

(James: is the above summary right?)

Comment 4

[James Socol [:jsocol, :james]]

That's basically my understanding, yeah. Given SUMO unique(ly non-technically savvy) user base, it seems like BID isn't currently the best way to help our users. ux-consistency says our current, well-understood username/password paradigm is probably better. (One might argue we could make that better and accept email addresses, which are unique for us.)

Now, we'd talked about doing BID initially only as an optional login path for contributors. But at present there doesn't seem to be any route to making it the only login path. I think we can use our limited resources more effectively right now.

Comment 5

[David Weir (satdav)]

can up date this and conform after reading 


Afrikaans (af) 	català (ca) 	Čeština (cs) 	Dansk (da)
Deutsch (de) 	Ελληνικά (el) 	Español (es) 	Eesti keel (et)
Euskara (eu) 	suomi (fi) 	Français (fr) 	Frysk (fy)
Gaeilge (ga) 	Hrvatski (hr) 	Italiano (it) 	Ligurian (lij)
Nederlands (nl) 	ਪੰਜਾਬੀ (pa) 	Polski (pl) 	Русский (ru)
slovenčina (sk) 	slovenščina (sl) 	Shqip (sq) 	Српски (sr)
Svenska (sv) 	Türkçe (tr) 	中文 (简体)
(zh-CN) 	正體中文 (繁體)
(zh-TW)

thats the following what browserID supports now

Comment 6

[Bram Pitoyo [:bram]]

There has been some discussions going on around this bug lately. Ibai and Ricky had started discussing, and I chimed in some opinions here for everyone to see and comment on.

The thing that the three of us was able to agree on was to deploy BrowserID as a convenience to contributors, but not to users at large.

BrowserID for a large majority of users:
* They will need an account in order to Ask A Question
* They don’t even need to login or care about usernames/password otherwise
* Users are familiar with needing an email in order to post a question. We tested this, and testers expected it
* Users are less familiar with needing a password in order to post. Some just wants to ask
* What users universally despised is the idea of having “one more thing to register for”
* A Kitsune account plus BrowserID makes for “two things to register for” == really bad for user expectation

BrowserID for contributors:
* Some of our users will need an account to contribute (AoA, KB, forums)
* Those who need to contribute will need to log in multiple times into SUMO
* These users are some of our heaviest and most vocal
* Since they already have an account, it’s not too much to ask them to register for one more thing: BrowserID
* Plus, there is a win on long-term convenience, so even if a new contributor will need to register two times, he will not mind the extra initial effort

Some of my concerns:
* In order to make BrowserID useful (ie. as a quick way to login), we must put it on the utility navigation section and have the button be on there
* However, most of our users won’t need to care about it. To them, registration is only needed for AAQ.
* If we hide BrowserID within the “login” page, it defeats the purpose of easy login, because autofill kicks in on the normal form, allowing you to login with one click


Proposed solution:
* Have BrowserID be present for contributors, as a convenience
* Have BrowserID be hidden to most users, who don’t need to care


How will we detect who’s a contributors, and who’s a regular user?

1. Referrer tracking
If visit comes from Google, we know that it’s probably not a contributor

2. Limit presence of the BrowserID button to certain pages that contributors tend to open
* I am assuming that most contributors do not access SUMO via the product help menu
* So, we can hide BrowserID on all product landing pages
* Contributors _may_ access SUMO by typing directly into their awesomebar or using a bookmark
* This means that we can show the BrowserID button on s.m.o/, the support forum, and all articles that is tagged with “contributors”

3. Track repeated viewing of the same page
* If a user had opened certain pages a lot of times (say, 5 times), he probably uses it a lot, and tends to be a heavy user
* Heavy user tends to be contributors
* So we could present the BrowserID button to them

Comment 7

[Bram Pitoyo [:bram]]

Attachment: Create new BrowserID, no existing Kitsune account

Please note that we’ll only show the BrowserID icon to contributors, as outlined in the last comment.

It turned out that the step is pretty simple, because a new registrant will only need to create a username to register (after undergoing email verification via BrowserID, of course).

I still think that it will benefit too minority of a userbase that the whole project of engineering BrowserID, plus targeting it to contributors only, all makes for a very expensive effort.

The wireframes did demonstrate that the UX integration and the steps involved are actually pretty simple. I haven’t spent a lot of time making these prototypes, and will wait for others to comment before I do any further work.

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

I agree that it seems like a lot of work that will only benefit a few new contributors that already have browser id get started in SUMO.

A few questions that come to mind so far:
* If you register through browser id, you won't be setting a password to login the old way. Correct?
* What happens to users that already have an account and sign in with browser id? Do we disable there password and force them to only use browser id from then on?

Comment 9

[Bram Pitoyo [:bram]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #8)
> * If you register through browser id, you won't be setting a password to
> login the old way. Correct?
> * What happens to users that already have an account and sign in with
> browser id? Do we disable there password and force them to only use browser
> id from then on?

Correct. You’ll have to choose between using BrowserID or username/password to log into SUMO.

Making both ways possible isn’t ideal, as the idea here is to increase BrowserID adoption amongst contributors. Once you upgrade, you can’t go back, so to speak.

Comment 10

[Kadir Topal [:atopal]]

I just tried the MDN implementation of BrowserID, and even for me it was at first rather confusing. The only benefit I can see is that existing browserID users would not need to set a new password, they would still need to choose a username though.

Since our user base is much less savvy than MDN we'd need to make sure that the implementation does not confuse users. As Bram has laid out there are a number of things to consider when doing that. Since we are short on resources I can't justify working on it in the foreseeable future. 

For any volunteer who wants to work on this, we need the following:

* A proposal for how the workflow would look like for users and contributors
** This would need to ensure that the browserID implementation is not more confusing then the current email/password method.
* An implementation that respects legacy accounts
** MDN might already have most of the code for this in Kuma.

If you are interested, leave a comment first before starting.

Comment 11

[David Weir (satdav)]

any update on this as it needs to happen asap

Comment 12

[François Marier [:francois]]

I think Persona makes sense on SUMO for both users and contributors if it's available *in addition* to the existing login system.

Here's a sketch of how it could work:

- ensure email addresses are unique in the database
- if someone logs in via Persona, look up the email and log that user in (if it's not there, create a new user account with username = email)

- offer both Persona and username/password on the login and registration pages
- "gray out" / hide the Persona button and enable it in Javascript (i.e. users without Javascript won't see it / be able to click on it)

- make passwords optional in the DB
- accounts w/o a password will require Persona for login
- accounts with a password support both Persona and regular logins

In other words, existing accounts don't change at all but they gain the ability to also login using Persona. Contributors can choose how they want to login and new users can create a Persona-only account or a regular password-based account that will work with both systems.

Comment 13

[François Marier [:francois]]

I also had a chat with Bram about this and we were discussing how we could simplify account creation for new users (not contributors). One way would be to split these new users into two categories:

1. new users with Javascript
2. new users without Javascript

The second category would not see any of the Persona stuff and would use the current login and account creation system.

The first category would see a Persona button *instead* of the "Create a support account" block on the registration page. So most new accounts would be Persona-only accounts.

Another change would be to skip the email confirmation steps in the case of Persona accounts. (The email you get from Persona is already verified.)

Comment 14

[Swarnava Sengupta (:Swarnava)]

if you guyz are planning to add persona/browserid support on SUMO, please make both normal way to sign in and Persona. because Persona dont work fine with my slow connection. i have problem to login with persona on site like mozillians, MDN etc.. if possible, please implement like bugzilla so that user can login both normal way and browserid too!

Comment 15

[François Marier [:francois]]

(In reply to Swarnava Sengupta (:Swarnava) from comment #14)
> if you guyz are planning to add persona/browserid support on SUMO, please
> make both normal way to sign in and Persona.

That's my recommendation as well. Persona would be another way to login into your account but would not replace the existing username&password scheme.

I've emailed you privately to follow up regarding the problems you're having with your slow connection. We definitely want to investigate that.

Comment 16

[David Weir (satdav)]

do we have a update if we are going to add it or not

Comment 17

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

Triaging this bug for SUMO bug day. I personally would not want this to happen but Ricky, do we know if we're going to move forward with this or should we close since it just won't happen?

Comment 18

[Ricky Rosario [:rrosario, :r1cky]]

There is discussion about this, but it's not up to me to make the final call.

Comment 19

[François Marier [:francois]]

Persona now has identity bridging for Yahoo addresses and is about to have it (Q2 goal) for GMail as well. Hotmail is next.

It might be worth keeping this bug open since having a near-native experience for 80% of users might make the account creation experience easier on SUMO.

Comment 20

[Bram Pitoyo [:bram]]

Having Yahoo, Gmail and Hotmail identity bridging would allow new AAQ user to skip the sign-up process for SUMO, if they are already signed into either one of those email providers. This would make for a good user experience.

Keep in mind that we have yet to discuss what this means for existing, non-Persona users. But for new users, this seem to make a lot of sense.

Our mobile users will benefit, as well, if they access their webmail via the browser and thus are already signed in by the time they use SUMO. If users mostly set up and check their mail using Email.app, it won’t make a big difference.

Comment 21

[Jacob [:Jacob]]

Just want to say that it would be a BIG win to have Persona on SUMO because all of the Webmaker users and mentors have Persona accounts. It would greatly ease the barriers of participating in forums for both users and volunteers if they didn't have to register for a separate SUMO account.

Please consider adding it in SUMO, it would be really great to have!

Comment 22

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

(In reply to Jacob [:Jacob] from comment #21)
> Just want to say that it would be a BIG win to have Persona on SUMO because
> all of the Webmaker users and mentors have Persona accounts. It would
> greatly ease the barriers of participating in forums for both users and
> volunteers if they didn't have to register for a separate SUMO account.
> 
> Please consider adding it in SUMO, it would be really great to have!

It's currently on stage; https://support.allizom.org/en-US/home

Comment 23

[Kadir Topal [:atopal]]

We'll switch as soon as people can sign up for Persona using non-Gmail email accounts: https://github.com/mozilla/browserid/issues/4003

Comment 24

[Kadir Topal [:atopal]]

on Firefox OS that is.

Comment 25

[Ricky Rosario [:rrosario, :r1cky]]

We are removing persona.

Comment 27

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #25)
> We are removing persona.

Can anyone explain me why?

Think Persona is the Mozilla Login Manager ... So why don't use it everywhere?

Comment 28

[Dan Callahan [:callahad]]

(In reply to Tobias B. Besemer from comment #27)
> (In reply to Ricky Rosario [:rrosario, :r1cky] from comment #25)
> > We are removing persona.
> 
> Can anyone explain me why?

While still supported and used, Persona is not being developed by Mozilla anymore. :(

Comment 29

[Will Kahn-Greene [:willkg] ET needinfo? me]

This work was done so long ago that I don't remember all the details, but the reason we ended up not adding Persona to SUMO was something along these lines:

1. there were problems with Persona and iOS.

2. if you were using Firefox OS and going through the AAQ flow and didn't have a Persona account, then you'd end up with a modal to create a Persona account that you couldn't make go away until after you activated. but you couldn't activate it without checking your email. but you couldn't check your email because if you did that, the modal would go away. thus you couldn't create a new account during the AAQ flow.


The first one was an issue, but we decided having Persona was more important so if this was the only issues we probably would have gone forward.

The second was a complete show-stopper since we needed to support Firefox OS users.

We tried a variety of different UX designs including supporting multiple kinds of accounts, but we just couldn't make it fly well enough so we abandoned the effort.

Comment 30

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Will Kahn-Greene [:willkg] from comment #29)
> This work was done so long ago that I don't remember all the details, but
> the reason we ended up not adding Persona to SUMO was something along these
> lines:

Thx for your detail answer. :-)

That's all now one year ago ... still the same issues?
Time to reopen the bug?

Comment 31

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Dan Callahan [:callahad] from comment #28)
> (In reply to Tobias B. Besemer from comment #27)
> > (In reply to Ricky Rosario [:rrosario, :r1cky] from comment #25)
> > > We are removing persona.
> > 
> > Can anyone explain me why?
> 
> While still supported and used, Persona is not being developed by Mozilla
> anymore. :(

Even if it is not developed by Mozilla anymore, I think Mozilla have so much logins on so much pages, that a single login should be really given to the users/supporters.
And because I don't know a other/better one that is OSS and not just a product of a company and because Persona is implemented nearly everywhere on the Mozilla Domains now ...
(OK, OpenID would be a other solution ...)

Comment 32

[Will Kahn-Greene [:willkg] ET needinfo? me]

(In reply to Tobias B. Besemer from comment #30)
> (In reply to Will Kahn-Greene [:willkg] from comment #29)
> > This work was done so long ago that I don't remember all the details, but
> > the reason we ended up not adding Persona to SUMO was something along these
> > lines:
> 
> Thx for your detail answer. :-)
> 
> That's all now one year ago ... still the same issues?
> Time to reopen the bug?

To my knowledge, yes--same issues.

The showstopper one is here:

https://github.com/mozilla/persona/issues/4003

That was closed because it was too old, but it's still a problem.

We should stop discussing this here since this bug is done and over and not going to be reopened. If you feel strongly about having a Persona login, please take it to the SUMO forums <https://support.mozilla.org/en-US/forums> or the mailing list <https://lists.mozilla.org/listinfo/dev-sumo>. Thank you!