Hook up django-allauth

[jezdez]

https://github.com/pennersr/django-allauth seems to be the latest hot thing (well maintained, tested etc).

[groovecoder]

Our most-likely Auth providers will be:

• GitHub OAuth
• Twitter OAuth
• StackExchange OAuth
• Firefox Accounts OAuth (very early stages)

[lmorchard]

I'm all for never, ever, ever keeping passwords again. The big project here, I think, will be setting up the transitional / connection flows. I don't think I've ever seen any 3rd party project support this stuff well. For example:

• New account? We can try pre-filling some profile details.
• Already logged in via Persona? Promote the new auth methods to users. "Now you can connect using {foo}!" And we need to support multiple auth pathways to 1 account
• Accidentally created a new account when you really meant to connect to an existing account? We'll need to support account deletion and connect 3rd party auth to a different account.
• We could also support many-to-many for mapping auth to accounts, but the UI on that would probably be a nightmare.
• Start nagging people if/when Persona gets deprecated. "Persona is going away on {date}. Please connect to your account using one of these methods, etc, etc, etc"
• Persona already deprecated? Enter your email address for a temporary login link, and that link goes directly to "Connect your account to one of these services for future logins..."
• We should also be able to consider add-on benefits of connecting with one of those services. It would really help us if we could explain to users what's in it for them. Better social sharing? What can we do with GitHub, etc?

All the above are things that made me cranky about Fx Accounts, too. :)

[groovecoder]

Is it possible and helpful to add django-allauth to our stack behind a waffle flag to experiment with it and explore how it may or may not address the UX concerns?

And/or should we bring UX into this idea immediately?

[lmorchard]

FWIW, wanted to pursue a little due diligence beyond django-allauth.

I started looking at python-social-auth, at least from a high level. It looks pretty well maintained like django-allauth, though it might be too generic since it aims to serve all kinds of Python frameworks beyond Django.

Meh, probably just a matter of picking a base library and going with it.

[lmorchard]

Heh, though some quick Twitter digging reveals that @jsocol found python-social-auth problematic and had success with django-allauth. This leads me to favor just going with django-allauth :smiley:

[groovecoder]

That seals it for me. django-allauth all the way!

[jsocol]

I should update that...

I also found allauth to be a PITA. It depends what you want to do. If you want "log in with X" I just did it my damn self, because neither of them seemed to directly support that use. If you want "connect your X account" after you've logged in with something else, python-social-auth is great, that's exactly what it does.

[lmorchard]

Hmm, yeah, I am kind of half tempted to just DIY the OAuth stuff if only because I feel like our login process has often been a bit of a precious special little snowflake and all the gotchas & exceptions will kill the helpful generality of a 3rd party app.

(also: Hi James! :grin:)

[lmorchard]

Starting work on this & bug 991351. Going to comment here, because it will probably be easier to revise a little progress report than fill the bug with comments.

Progress so far:

• [x] Installed django-allauth into kuma-lib
• [x] Installed the allauth apps into kuma
• [x] allauth supports persona login, needed a bugfix to make Django recognize HTTPS via mod_proxy
• [ ] allauth does not "Automatically associate GH account to MDN account".
  • By default, it requires the 3rd party identity to have been connected beforehand to a logged-in profile from a control panel it offers. Otherwise, new profile creation is prompted.
  • FWIW, this is more secure than trusting the 3rd party email, but not convenient.
  • Following a lead: allauth supports a pre_social_login signal that I might be able to use as a hook to auto-associate with an existing account via matching email address present in the 3rd party identity
• [ ] allauth does its own account registration, needs adaptation to our custom process tied to browserid
• [x] allauth uses ~31 Django templates that need to be adapted to Kuma's Jinja template engine
• [x] allauth has its own UX flow, needs to be adapted to our proposed UX
• [x] allauth offers username & password auth, needs to be disabled
• [ ] Need to implement a waffle flag to switch between old browserid and new allauth
• [x] github requires a single OAuth callback URL. This clashes with our locale-in-the-URL pattern that results in many URLs like /{en-US,fr,de}/accounts/login/callback/. May need to just make sign-in a locale-free set of URLs and rely on the browser accept-language headers.
• [ ] allauth handles the email address verification dance. This might either need to be disabled - or it could turn out handy for cases where the github email address is unvalidated or we don't trust it

More to come as I work through wiring up the app. When this list stops growing, and I've checked everything off, then I'll be ready to submit an initial pull request.

[jezdez]

BTW, this is a great presentation about auth systems in Django: https://speakerdeck.com/tedtieken/signing-up-and-signing-in-users-in-django-with-django-allauth

[pennersr]

@jsocol "If you want "log in with X" I just did it my damn self, because neither of them seemed to directly support that use." -- could you please elaborate a bit? With allauth, if you have auto signup enabled, a "login with X" is merely a matter of linking to "/accounts/X/login/". In any case, I am interested to learn if anything can be done to accomodate for your use case ...

[jezdez]

Oh hey, this is fixed btw!

[jsocol]

@pennersr happy to follow-up offline here, me@jamessocol.com, but this was 4 months ago so my memory is not going to be spot on.