provide Medium-style email authentication

[chadwhitacre]

We should provide Medium-style email authentication.

Old

We should provide password authentication. You should be able to use either your username and/or an email address (which one? only primary? configurable per-address?). This ticket started out being about signing up with email, but the actual important/hard part is the password authentication.

We first discussed email sign-up on #89, but that became more about linking email accounts to existing Gittip accounts rather than using email to sign up in the first place. Here's a ticket about signing up with email in the first place, in response to a request I received in private email:

Is there a way to give money without signing up for Twitter, etc.?

We currently rely on social network profiles to detect fraud. It does limit our reach, however.

Notify:

• https://gratipay.freshdesk.com/helpdesk/tickets/2358
• https://gratipay.freshdesk.com/helpdesk/tickets/2749
• https://gratipay.freshdesk.com/helpdesk/tickets/3213
• https://gratipay.freshdesk.com/helpdesk/tickets/6349

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

This would be important for nice on-site user flows as with #737.

[chadwhitacre]

Social accounts are the basis of our anti-fraud.

[chadwhitacre]

See also #756.

[chadwhitacre]

+1 from @traverseda at #1657 (comment).

[chadwhitacre]

I closed this during a ticket purge a couple months ago. Still worth tracking, I think.

Requested by @oeekker via [email protected].

[chadwhitacre]

+1 from @philipn on #1732.

[chadwhitacre]

+1 from @alexpott in IRC.

[patcon]

+1 because I need to give the billing person at my company access to manage invoices, but we DON'T want to give her the twitter login credentials, because that's something only marketing should be logging into.

[duckinator]

I believe this would be handled with Persona support, and am marking it as such in the meta-issue for the onboarding process. Let me know if this is incorrect and I'll update the meta-issue accordingly.

[chadwhitacre]

@duckinator I'm still not sure on the relationship between Persona and password authentication. For the onboarding flow optimizations (#1167) I thought we were going to stick with the existing login options, no?

[duckinator]

@whit537 the most you need to use Persona is an email address and a password. For some providers (ie, GMail), it'll offload you to their OAuth servers, but you still only need your email address and password. Does that resolve the issue here, or not?

---

As discussed on IRC, I'm removing this from #1894.

[chadwhitacre]

+1-ish from @nslater (Engine Yard) via support@.

[pjf]

+1 from yours truly. :)

[zbynekwinkler]

If we are willing to trust https://trustcloud.com/ we could use that to help our anti fraud techniques. I have just created account there and it looks good so far https://trustcloud.com/!/zwn

[patcon]

+1 to trustcloud. I'm going to let them know the ways we're considering using their service

[oeekker]

See also this blog about Persona and it not being too secure:
http://benjamin.smedbergs.us/blog/2014-02-11/dont-use-mozilla-persona-to-secure-high-value-data/

[chadwhitacre]

@oeekker We're also discussing that over on #756.

[oeekker]

Thanks for the pointer @whit537

[chadwhitacre]

@oeekker :-)

[EdOverflow]

I found the solution to this issue: https://youtu.be/VgC4b9K-gYU

[mattbk]

Would like to see #638 (2FA) as part of this.

[rohitpaulk]

Thinking about how we can split this into small pieces:

• Split out dedicated sign-in/sign-up pages. As a side effect, this also helps solve 1) the unfriendly 401 page problem (Email link UX issue #4489) 2) Confusion around using the wrong third-party account to sign-in, ends up creating a new account - which requires account merging to fix.
• Allow sign-in via email (under a beta query param) such that any existing verified email address can be used. Things to think about: 1) Rate limiting/Captcha
• Allow sign-up via email (under a beta query param). Things to think about: 1) Rate limiting/Captcha 2) Claim username before email confirmation or after? 3) Participants with zero social logins - make sure no assumptions are left across codebase?
• Remove feature flag for sign-up and sign-in via email

[chadwhitacre]

@rohitpaulk In terms of user experience (and apart from the side effects), what's the purpose of separating sign-in and sign-up?

I was envisioning a process like Medium's, where email is just another of several options under "Sign in / Sign up."

[rohitpaulk]

In terms of user experience (and apart from the side effects), what's the purpose of separating sign-in and sign-up?

By knowing the intent, we'll be able to provide better feedback. Two separate pages is just one way of addressing this, can also be done using better UI feedback on a single page. What I want to solve is "Confusion around using the wrong third-party account to sign-in, ends up creating a new account - which requires account merging to fix.". For example, we shouldn't just 'create' a new account if the user intended to sign-in using a third-party provider but chose the wrong one.

I'll take a look at how Medium handles this, I expect that they'd place an intermediary step between registration (something like "You don't have an account, we're going to create one for you. Are you sure?") to prevent accidentally creating a new account

[chadwhitacre]

@rohitpaulk We've talked before about phasing out social logins entirely, and requiring an email for everyone on Gratipay: #3837. Do you think we should move in that direction? If so, how does that affect the steps we take here?

[rohitpaulk]

We've talked before about phasing out social logins entirely, and requiring an email for everyone on Gratipay: #3837. Do you think we should move in that direction? If so, how does that affect the steps we take here?

That ticket is blocked on this (we can't remove other authentication methods before we introduce email), but I don't think the steps we take here must be affected by that ticket.

[rohitpaulk]

A few rough designs I'm experimenting with:

Dedicated Sign-in page - 1

Dedicated Sign-in page - 2

Dedicated Sign-in page - 3

Sign-in modal - 1

Sign-in modal - 2

Sign-in modal - 3

Sign-in modal - 4

[rohitpaulk]

I propose that this be done in stages - we'll first split the sign-in/sign-up action into a modal, with support only for third-party providers. This will be friendlier on mobile than the current drop-down, and makes space for adding the email option.

Once that is done, we'll add support for email and introduce that option in the UI.

[rohitpaulk]

(Note: The serif font is not the one we use on production, I couldn't find a downloadable version on our typography.com account)

[chadwhitacre]

Sounds good.

Re: font ... if you use localhost:8537 it should work as that is whitelisted. Otherwise you can probably add whatever you're using instead to the whitelist on typography.com?

[rohitpaulk]

if you use localhost:8537 it should work as that is whitelisted

These designs are from Adobe XD, not in a browser 😄. Our typography account had Ideal Sans as a downloadable font, but not Typewriter.

[chadwhitacre]

Hah! Oh. :-)

Typewriter doesn't sound familiar. Our serif is ... Chronicle, I think?

[rohitpaulk]

Typewriter doesn't sound familiar.

Hmm, wonder where I got that from

Our serif is ... Chronicle, I think?

Yes, yes

[chadwhitacre]

Sign-in modal is deployed!

https://twitter.com/Gratipay/status/879365201665064961

[rohitpaulk]

Moving on to the next step. I'm first going to enable sign-in (not signup) via email, under a feature flag (to test). After that, will look at sign-up via email

[mattbk]

+1 from #4554 (comment)

[chadwhitacre]

Closing in light of our decision to shut down Gratipay.

Thank you all for a great run, and I'm sorry it didn't work out! 😞 💃