On Tue, Aug 30, 2016 at 12:17 AM, <[email protected]> wrote:
> It's sparse, because it re-uses the existing account verification
> end-points. The flow goes like this:
>
> * Submit credentials to /v1/account/login [1].
>
> * For whatever reason, the server decides the request needs
> additional verification. It sends the email and includes the
> following fields in the response body:
>
> {
> "verified": false,
> "verificationReason": "login",
> "verificationMethod": "email",
> [...other existing login response fields here...]
> }
>
> * The email includes a link with a verification code, in exactly
> the same way as the existing account-verification email.
>
> * When clicked, this link loads a page that submits the code
> to /v1/recovery_email/verify_code [2]
>
I'm not sure how this makes it possible for me to use the Sync API like I
had previously. My app POSTs to account/login and gets back enough info for
me to retrieve the key needed to decrypt my bookmark data. I get that key
by accessing the crypto/keys storage object using the current Storage APIs.
The process all happens synchronously, and is non-interactive from the
moment I click a button on a web page to when the decrypted bookmark data
gets rendered to a web page. I read the above links but it's not clear how
they will allow me to get to my bookmark data. And it's only bookmark data
I care about.
How can I use this new security framework in my app to achieve the same
thing? Is it even possible given the flow I described?
Chris
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev