Skip to content
This repository has been archived by the owner. It is now read-only.

feat(client): Sync state with the browser! #4695

Merged
merged 4 commits into from May 25, 2017

Conversation

@shane-tomlinson
Copy link
Member

@shane-tomlinson shane-tomlinson commented Feb 2, 2017

Very early stage yet, putting this up so we don't forget about it. Goes along with https://bugzilla.mozilla.org/attachment.cgi?id=8832820

Perform a handshake with the browser to use the browser as the canonical
source of truth when it comes to signed in accounts.

issue #4252
https://bugzilla.mozilla.org/show_bug.cgi?id=1308038

/**
* A variant of the FxSync broker that speaks "v4" of the protocol.
*
* It used to enable syncPreferencesNotification on the verification complete screen.

This comment has been minimized.

@shane-tomlinson

shane-tomlinson Mar 2, 2017
Author Member

This comment lies.

@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch 5 times, most recently from 8dab6bf to 7dd3bec Mar 3, 2017
@shane-tomlinson shane-tomlinson changed the title [WIP] feat(client): Sync state with the browser! feat(client): Sync state with the browser! Mar 3, 2017
@shane-tomlinson
Copy link
Member Author

@shane-tomlinson shane-tomlinson commented Mar 3, 2017

This is no longer WIP and ready to go. This goes along with the Firefox patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1308038

@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch from 7dd3bec to 62da580 Mar 3, 2017
@shane-tomlinson shane-tomlinson requested review from rfk and vladikoff Mar 3, 2017
@shane-tomlinson
Copy link
Member Author

@shane-tomlinson shane-tomlinson commented Mar 3, 2017

@rfk, @vladikoff - no rush on this, mind starting an r when you have time? Testing requires m-c w/ the browser patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1308038.

Copy link
Member

@rfk rfk left a comment

This looks good to me, but I want to dig into the interaction between localStorage and private-browsing mode just in case there are any edge-cases to worry about here.

account.set(_.pick(userData, 'email', 'sessionToken', 'uid', 'verified'));
account.set('sessionTokenContext', SESSION_TOKEN_USED_FOR_SYNC);

return user.setSignedInAccount(account);

This comment has been minimized.

@rfk

rfk Mar 6, 2017
Member

This persists the data from the handshake into localStorage, right? I wonder whether that will cause trouble for us when using this in private browsing mode, if the data so written then becomes available to other tabs in the same private-browsing window. I'll try to build m-c with this patch and find out, but it will take a while as I don't have my dev environment set up on this machine yet...

This comment has been minimized.

@shane-tomlinson

shane-tomlinson Mar 6, 2017
Author Member

You are correct, we write to this tab's localStorage so the data will be available even in PB mode to subsequent browses to an OAuth relier in this same tab. If we avoid writing to localStorage, we'll break users of non-PB mode who subsequently visit an OAuth relier.

return user.setSignedInAccount(account);
} else {
const signedInAccount = user.getSignedInAccount();
user.removeAccount(signedInAccount);

This comment has been minimized.

@rfk

rfk Mar 6, 2017
Member

Is there anything in the account that we should destroy at this point, e.g. oauth tokens?

This comment has been minimized.

@shane-tomlinson

shane-tomlinson Mar 6, 2017
Author Member

That question can be applied more broadly about how we should be handling signed out accounts. I have a feeling that's a can of worms that'll explode this PR and could be handled independently.

});

describe('capabilities', () => {
it('has the `allowUidChange` capability', () => {

This comment has been minimized.

@rfk

rfk Mar 6, 2017
Member

This test title is the only occurrence of "allowUidChange" in the PR, is it a hangover from a previous naming convention?

This comment has been minimized.

@shane-tomlinson

shane-tomlinson Mar 6, 2017
Author Member

copy/paste error

@rfk
Copy link
Member

@rfk rfk commented Mar 6, 2017

I want to dig into the interaction between localStorage and private-browsing
mode just in case there are any edge-cases to worry about here.

Actually, it's not clear precisely how this is enforcing the 'only request "fxa_status" IFF service=sync' requirement from https://bugzilla.mozilla.org/show_bug.cgi?id=1308038#c27; it looks like it will request status from the browser whenever context=fx_desktop_v4, but does that guarantee that service=sync?

@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch from 3825534 to bee596a May 24, 2017
shane-tomlinson pushed a commit that referenced this pull request May 24, 2017
The move is so these mixins can be used by any objects. This is an extraction
from #4695.

issue #4252
shane-tomlinson pushed a commit that referenced this pull request May 24, 2017
@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch from bee596a to 5c1641e May 24, 2017
shane-tomlinson pushed a commit that referenced this pull request May 24, 2017
The move is so these mixins can be used by any objects. This is an extraction
from #4695.

issue #4252
vladikoff added a commit that referenced this pull request May 24, 2017
vladikoff added a commit that referenced this pull request May 24, 2017
#5099) r=vladikoff

The move is so these mixins can be used by any objects. This is an extraction
from #4695.

issue #4252
@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch from 5c1641e to b89af11 May 24, 2017
@shane-tomlinson shane-tomlinson force-pushed the issue-4252-sync-me-with-the-browser branch from b89af11 to b6b54c9 May 24, 2017
@shane-tomlinson
Copy link
Member Author

@shane-tomlinson shane-tomlinson commented May 24, 2017

@mozilla/fxa-devs - r? I'm calling this ready. This patch works for real using today's Nightly. Use fxa-dev-launcher to point to a local install, and give it a whirl!

Things to test:

  • Sign in to Sync, clear history, open about:preferences#sync and click "Manage Account"
  • Sign in to Sync, open a private browsing window, open about:preferences#sync and click "Manage Account"
  • Set history settings to "Never remember" (permanent Private Browsing mode), sign in to Sync, open a private browsing window, open about:preferences#sync and click "Manage Account".
  • With no user signed in to Sync, sign into an OAuth relier. Sign into Sync (user will not be pre-filled). Sign into the OAuth relier again, when redirecting to FxA, original email used to sign into relier should be remembered.
  • With a user signed in to Sync, sign into an OAuth relier - at FxA, Sync user should be prefilled. Sign into the OAuth relier again, when redirecting to FxA, Sync email should still be remembered.

Another thing to note - I've started a selectors file for the functional tests - https://github.com/mozilla/fxa-content-server/pull/4695/files#diff-fc925842e92dad5a948ae59844a1a901. Instead of hard coding selectors in the tests, let's add entries to that file.

* Defaults to `this.getUserAgentString()`
* @returns {Boolean}
*/
isFxaStatusSupported (userAgent = this.getUserAgentString()) {

This comment has been minimized.

@philbooth

philbooth May 25, 2017
Contributor

TIL that default values can be function calls and have access to this.


const channel = this._notificationChannel;
return p().delay(TEST_REQUEST_DELAY_MS)
// OAuth reliers will have `service` set to the client_id, Sync to `sync`

This comment has been minimized.

@philbooth

philbooth May 25, 2017
Contributor

Not sure if it's just me but part of this comment reads back to front. Should it be "...will have the client_id set to service"?

This comment has been minimized.

@philbooth

philbooth May 25, 2017
Contributor

No, it shouldn't. Sorry, just woken up here.

This comment has been minimized.

@shane-tomlinson

shane-tomlinson May 25, 2017
Author Member

I was just thinking this comment doesn't really provide any value. I'll just rip it out instead of causing more confusion. The comment on lines 125-127 are the informative ones.

// If trying to sign in to an OAuth relier, prefer any users that are
// stored in localStorage and only use the browser's state if no
// user is stored.
return !! (service === Constants.SYNC_SERVICE || this.getSignedInAccount().isDefault());

This comment has been minimized.

@philbooth

philbooth May 25, 2017
Contributor

Looks like the explicit !! is unnecessary here? === returns a boolean and so does account.isDefault(). Not a big deal obviously but may be a trifle more readable without it?

@philbooth
Copy link
Contributor

@philbooth philbooth commented May 25, 2017

@shane-tomlinson, this is great! LGTM, WFM, r+.

Shane Tomlinson added 2 commits May 25, 2017
* Remove a comment that makes no sense.
* Remove an extra !!, the value was always going to be Boolean anyways.
@shane-tomlinson shane-tomlinson merged commit 18fa0d5 into master May 25, 2017
4 checks passed
4 checks passed
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage decreased (-0.1%) to 97.776%
Details
@shane-tomlinson shane-tomlinson deleted the issue-4252-sync-me-with-the-browser branch May 25, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants