Ability to link an email address to an existing account.

[wyze]

Addresses #89.

[chadwhitacre]

Let's leave this line in. :-)

[chadwhitacre]

If I'm not mistaken we need to add a verification workflow, yes? We talked about mocking out Mandrill for testing. Should we go ahead and start using a queue for emails? That introduces another dependency.

[chadwhitacre]

Mandrill Python docs: https://mandrillapp.com/api/docs/index.python.html

[chadwhitacre]

I don't think we need a queue for emails because Mandrill basically is that for us. We need to write tests for the parts that call out to Mandrill, and for the parts the receive the link-back from Mandrill for verification.

[chadwhitacre]

Let's get this DONE. You still on this @wyze or should I take over?

[seanlinsley]

@whit537 mind if I work on this?

[MikeFair]

Why aren't we just using Mozilla's Persona here; this is exactly what
that's built for? Authenticating someone actually owns the email address
they're providing...
On Nov 10, 2013 8:09 PM, "Sean Linsley" notifications@github.com wrote:

@whit537 https://github.com/whit537 mind if I work on this?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1287#issuecomment-28172982
.

[seanlinsley]

@MikeFair I greatly prefer using Persona as I said in #756, but @whit537 seems against the idea. One way or another, Gittip needs to be able to contact its users before it's really going to be able to mature.

[MikeFair]

I bet if we took on Persona in this case as simply the way the site is
going to validate a user owns the email address at the time they enter it;
you'd get no objections. I think that's going to be good everyone to start
gaining experience with Persona so they can begin trusting it more.

#756 was about authenticating using Persona; for this case though, we can
set that issue aside and get it implemented.

On Sun, Nov 10, 2013 at 9:16 PM, Sean Linsley notifications@github.comwrote:

@MikeFair https://github.com/MikeFair I greatly prefer using Persona as
I said in #756 #756, but
@whit537 https://github.com/whit537 seems against the idea. One way or
another, Gittip needs to be able to contact its users before it's really
going to be able to mature.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1287#issuecomment-28174534
.

[zbynekwinkler]

👍 for Persona, I bet is is less work than implementing the verification of the email by hand.

[seanlinsley]

@callahad, @lloyd is it too weird to use Persona for email verification but not for auth? It certainly feels weird to me.

[callahad]

@seanlinsley Not weird. Our current API may feel a bit weird (it really wants to manage session state), but an effectively stateless API is coming in the next month, which will fit super cleanly into this use case.

[seanlinsley]

Awesome, thanks for the verification @callahad. We're currently focused on infrastructure improvements and are trying not to make user-facing changes, so the new API might be in place before we get around to this :)

[zbynekwinkler]

@callahad Has the stateless API happened? We'd like to clean up our PR queue this week.

[zbynekwinkler]

It seems to me that this is it: https://developer.mozilla.org/en-US/Persona/Remote_Verification_API?redirectlocale=en-US&redirectslug=Persona%2FRemote_Verification_API
Judging from https://github.com/mozilla/PyBrowserID

For the vast majority of deployments, you will simply want to call the module- level "verify" functon to verify a given assertion:

>> data = browserid.verify(BROWSERIDASSERTION, "http://mysite.com")
>> print data["email"]
"test@example.com"

The precise implementation of this function will change depending on the current recommendations of the BrowserID team. Currently it POSTs the assertion to the remote verifier services on persona.org.

It should be really easy to integrate.

[zbynekwinkler]

In combination with https://developer.mozilla.org/en-US/Persona/The_navigator.id_API#The_Callback_API we can be set. I guess we just call https://developer.mozilla.org/en-US/docs/Web/API/navigator.id.get and verify the result like the above and be done with it (?).

[callahad]

@zwn Unfortunately, our internal commitments to other teams prevented us from getting this into production -- we didn't want to push a release that hadn't been fully QA'd, nor release too close to holiday vacations. At this point, I believe the final API is 4-6 weeks from production.

I'd suggest using the "Observer API" (.watch(), .request(), and .logout()), as it is the most robust, most tested, and will have the simplest upgrade path to the new API.

@zwn, are you doing the implementation, or someone else? I'd love to chat and put together some short notes to make it easier to avoid some of the weird corner cases when you don't want Persona's default statefulness.

[zbynekwinkler]

@callahad I am not the one doing the implementation. I am just trying to figure out if we have all the pieces together and prioritize (we are at @whit537 house continuing the gittip retreat). @duckinator is going to be coordinating our efforts around streamlining the sign up flow. I do most of my work on the backend.

You do not recommend the "Callback API"? It is supposed to be stateless and it seems it would fit our code base better. Going forward we would like to support both - just attaching email address using persona but not using it for sign in or going fully in. We would like to have this support for all our attached services/accounts, giving the user the option to pick the one they trust the most for sign in.

[callahad]

The "Callback API" (.get()) has issues with Chrome on iOS and IE Mobile on Windows Phone, the Observer API does not. We fixed that with the "Observer API," but over-shot and made things more complicated and state-ful than they needed to be. Turns out, API design is hard. :)

How about this: When you guys are sitting down to hack on this (or if you want to talk through a pull request), ping me here or on IRC ("callahad" on freenode and irc.mozilla.org) and I'll help review / brainstorm / etc.

[duckinator]

We're now planning to use Persona as authentication. I'm assuming we're going to use it for email verification, as well. If that assumption is correct, then what is the status of this pull request? Is it still useful?

[seanlinsley]

There seems to be a bit of code in this PR that we can copy, at least 🐱

[duckinator]

Yea. I have a suspicion that some of the code may be useful. But I don't know how exactly we plan to handle using Persona for email verification (will that even be separate from setting it up for authentication?), so I don't know what parts.

[clone1018]

Thank you @wyze . We merged this in by making a new PR without the old git cruft and it should be live in a couple of hours.

Thanks for getting the ball rolling :D