Closed Bug 905438 Opened 6 years ago Closed 6 years ago

Implement Android SyncAdapter class that syncs with Sync 1.1 against Firefox Account object

Categories

(Firefox for Android :: Android Sync, defect)

All
Android
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: nalexander, Assigned: rnewman)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qa+])

This is the pay-off bug for the Android Firefox Account bug tree: implementing an Android SyncAdapter that actually uses the Firefox Account object (and its contained data, like keys and session tokens, etc) to sync using the Sync 1.1 protocol and (hopefully!) android-sync code base.

At this point, there's a split in the road.  We can either make back-end changes to be more Sync 2.0 like, or we can make no back-end changes and do everything client side.

If we make back-end changes, we need to do the following as part of this:

* (back-end) deploy a token server that turns Persona certs into tokens (HAWK?)
* (back-end) deploy a Sync 1.1 server that auths using tokens (HAWK?)
* implement an Android HTTP token server library
* implement an Android BrowserID crypto library
* implement an Android getAuthToken method that returns a valid Persona assertion
* update the android-sync codebase to authenticate using the new token type (HAWK?)

If we don't make back-end changes, we need to:

* define and document how to derive Sync 1.1 user data (username, password, encryption key, and endpoint) from Firefox Account data
* if we want to allow *creating* accounts on Android:
** implement a Sync User 1.0 HTTP client
** create Sync User accounts during Firefox Account creation flow

In both cases, we will then have the auth credentials and crypto keys to actually sync using Sync 1.1.
(In reply to Nick Alexander :nalexander from comment #0)
> * (back-end) deploy a token server that turns Persona certs into tokens
> (HAWK?)
> * (back-end) deploy a Sync 1.1 server that auths using tokens (HAWK?)

Alternative:  Just send a BrowserID assertion in the Authorization header on every request.  Keep sending the same assertion until it expires.  The server will HMAC-and-memcache valid assertions to avoid validating them on every request.

This would cut down the amount of client *and* server code we have to write quite considerably.  It's not as nice as a token-based system, but it's not any worse than the current Basic Auth setup on the server.

I'm not worried about putting the code together for this, but the Ops overheads of running a second cluster might be more than we're willing to pay at this stage.  I'll try to dig into the details some more on that front.

(Hmm...come to think of it, we may even be able to run new-style and old-style auth side-by-side on the same cluster)

> * define and document how to derive Sync 1.1 user data (username, password,
> encryption key, and endpoint) from Firefox Account data
> * if we want to allow *creating* accounts on Android:
> ** implement a Sync User 1.0 HTTP client
> ** create Sync User accounts during Firefox Account creation flow

We could ease the pain a little here but not forcing you to solve a captcha when creating the shadow sync account.
(In reply to Ryan Kelly [:rfkelly] from comment #1)
> (In reply to Nick Alexander :nalexander from comment #0)
> > * (back-end) deploy a token server that turns Persona certs into tokens
> > (HAWK?)
> > * (back-end) deploy a Sync 1.1 server that auths using tokens (HAWK?)
> 
> Alternative:  Just send a BrowserID assertion in the Authorization header on
> every request.  Keep sending the same assertion until it expires.  The
> server will HMAC-and-memcache valid assertions to avoid validating them on
> every request.

Sure.  BID assertions are fairly big -- about 2048 bits -- but this is definitely possible.

> > ** create Sync User accounts during Firefox Account creation flow
> 
> We could ease the pain a little here but not forcing you to solve a captcha
> when creating the shadow sync account.

Yeah, for experimentation we can stand against stage, which doesn't require captchas (IIRC).
Whiteboard: [qa+]
OS: Mac OS X → Android
Hardware: x86 → All
I'll be finishing up the SyncAdapter.
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: Android Background Services → Firefox for Android
You need to log in before you can comment on or make changes to this bug.