Add some brokers #1609
Add some brokers #1609
Conversation
|
||
initializeBroker: function () { | ||
if (this._searchParam('context') === 'fx_desktop_v1') { |
vladikoff
Aug 29, 2014
Contributor
Didn't we have a constant for this?
Didn't we have a constant for this?
pdehaan
Aug 29, 2014
Contributor
This seems awfully specific. Can we tweak this to use the Constants.FX_DESKTOP_CONTEXT
const?
$ grep -irn "fx_desktop_v1" . | grep -v "./\(dist\|.tmp\)/"
./app/scripts/lib/constants.js:15: FX_DESKTOP_CONTEXT: 'fx_desktop_v1',
./tests/server/metrics-collector-stderr.js:60: assert.equal(loggedMetrics.context, 'fx_desktop_v1');
./tests/server/metrics-collector-stderr.js:89: context: 'fx_desktop_v1',
./tests/tools/firefox_profile_creator.js:26: myProfile.setPreference('identity.fxaccounts.remote.force_auth.uri', profile.fxaContentRoot + 'force_auth?service=sync&context=fx_desktop_v1');
./tests/tools/firefox_profile_creator.js:27: myProfile.setPreference('identity.fxaccounts.remote.signin.uri', profile.fxaContentRoot + 'signin?service=sync&context=fx_desktop_v1');
./tests/tools/firefox_profile_creator.js:28: myProfile.setPreference('identity.fxaccounts.remote.signup.uri', profile.fxaContentRoot + 'signup?service=sync&context=fx_desktop_v1');
$ grep -irn "Constants.FX_DESKTOP_CONTEXT" . | grep -v "./\(dist\|.tmp\)/"
./app/scripts/lib/session.js:140: return this.get('context') === Constants.FX_DESKTOP_CONTEXT;
./app/scripts/views/settings.js:28: showSignOut: Session.get('sessionTokenContext') !== Constants.FX_DESKTOP_CONTEXT
./app/scripts/views/sign_in.js:106: if (Session.get('context') !== Constants.FX_DESKTOP_CONTEXT) {
./app/tests/spec/lib/app-start.js:29: return '?context=' + Constants.FX_DESKTOP_CONTEXT;
./app/tests/spec/lib/router.js:67: windowMock.location.search = '?context=' + Constants.FX_DESKTOP_CONTEXT;
./app/tests/spec/lib/router.js:69: assert.equal(navigateUrl, '/forgot?context=' + Constants.FX_DESKTOP_CONTEXT);
./app/tests/spec/views/settings.js:78: Session.set('sessionTokenContext', Constants.FX_DESKTOP_CONTEXT);
./tests/functional/settings.js:80: .get(require.toUrl(SIGNIN_URL + '?context=' + Constants.FX_DESKTOP_CONTEXT))
This seems awfully specific. Can we tweak this to use the Constants.FX_DESKTOP_CONTEXT
const?
$ grep -irn "fx_desktop_v1" . | grep -v "./\(dist\|.tmp\)/"
./app/scripts/lib/constants.js:15: FX_DESKTOP_CONTEXT: 'fx_desktop_v1',
./tests/server/metrics-collector-stderr.js:60: assert.equal(loggedMetrics.context, 'fx_desktop_v1');
./tests/server/metrics-collector-stderr.js:89: context: 'fx_desktop_v1',
./tests/tools/firefox_profile_creator.js:26: myProfile.setPreference('identity.fxaccounts.remote.force_auth.uri', profile.fxaContentRoot + 'force_auth?service=sync&context=fx_desktop_v1');
./tests/tools/firefox_profile_creator.js:27: myProfile.setPreference('identity.fxaccounts.remote.signin.uri', profile.fxaContentRoot + 'signin?service=sync&context=fx_desktop_v1');
./tests/tools/firefox_profile_creator.js:28: myProfile.setPreference('identity.fxaccounts.remote.signup.uri', profile.fxaContentRoot + 'signup?service=sync&context=fx_desktop_v1');
$ grep -irn "Constants.FX_DESKTOP_CONTEXT" . | grep -v "./\(dist\|.tmp\)/"
./app/scripts/lib/session.js:140: return this.get('context') === Constants.FX_DESKTOP_CONTEXT;
./app/scripts/views/settings.js:28: showSignOut: Session.get('sessionTokenContext') !== Constants.FX_DESKTOP_CONTEXT
./app/scripts/views/sign_in.js:106: if (Session.get('context') !== Constants.FX_DESKTOP_CONTEXT) {
./app/tests/spec/lib/app-start.js:29: return '?context=' + Constants.FX_DESKTOP_CONTEXT;
./app/tests/spec/lib/router.js:67: windowMock.location.search = '?context=' + Constants.FX_DESKTOP_CONTEXT;
./app/tests/spec/lib/router.js:69: assert.equal(navigateUrl, '/forgot?context=' + Constants.FX_DESKTOP_CONTEXT);
./app/tests/spec/views/settings.js:78: Session.set('sessionTokenContext', Constants.FX_DESKTOP_CONTEXT);
./tests/functional/settings.js:80: .get(require.toUrl(SIGNIN_URL + '?context=' + Constants.FX_DESKTOP_CONTEXT))
pdehaan
Aug 29, 2014
Contributor
Plus, now looking through those beautiful greps, not sure if it would help to have some isDesktopContext()
helper function since it seems like we're doing some variation of this in at least 3 places now:
if (this._searchParam('context') === 'fx_desktop_v1') {...}
Actually, it looks like we have one in /app/scripts/lib/session.js:139:
isDesktopContext: function () {
return this.get('context') === Constants.FX_DESKTOP_CONTEXT;
},
Plus, now looking through those beautiful greps, not sure if it would help to have some isDesktopContext()
helper function since it seems like we're doing some variation of this in at least 3 places now:
if (this._searchParam('context') === 'fx_desktop_v1') {...}
Actually, it looks like we have one in /app/scripts/lib/session.js:139:
isDesktopContext: function () {
return this.get('context') === Constants.FX_DESKTOP_CONTEXT;
},
shane-tomlinson
Aug 29, 2014
Author
Member
So, the idea is that the broker knows that it is in the desktop context and everything else has no need to know, and isDesktopContext
can be ripped out of Session. I'll update to use the named string from Constants.
So, the idea is that the broker knows that it is in the desktop context and everything else has no need to know, and isDesktopContext
can be ripped out of Session. I'll update to use the named string from Constants.
}, | ||
|
||
/** | ||
* Initialize the Session. Perhaps should be merged into `fetch` |
pdehaan
Aug 29, 2014
Contributor
Perhaps should be merged into fetch
My eyes say "docs comment", but my heart almost says "TODO".
ಠ_ಠ
Perhaps should be merged into
fetch
My eyes say "docs comment", but my heart almost says "TODO".
ಠ_ಠ
shane-tomlinson
Aug 29, 2014
Author
Member
Good catch.
Good catch.
beforeEach(function () { | ||
Session.clear(); | ||
|
||
email = 'testuser.' + Math.random() + '@testuser.com'; |
|
||
view.remove(); | ||
view.destroy(); | ||
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT'; |
pdehaan
Aug 29, 2014
Contributor
This looks very similar to line 439 above. Not sure if we should move this hardcoded cookie string somewhere higher into a constant or helper somewhere.
$ grep -irn "tooyoung=1" app
Results:
-
app/scripts/views/clear_storage.js:24:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
-
app/scripts/views/sign_up.js:173:
document.cookie = 'tooyoung=1;';
-
app/tests/spec/views/sign_up.js:53:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
-
app/tests/spec/views/sign_up.js:76:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
Something like TOO_YOUNG_COOKIE = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
in /app/scripts/lib/constants.js and then in the src we could just use it as document.cookie = Constants.TOO_YOUNG_COOKIE;
(or whatever).
This looks very similar to line 439 above. Not sure if we should move this hardcoded cookie string somewhere higher into a constant or helper somewhere.
$ grep -irn "tooyoung=1" app
Results:
-
app/scripts/views/clear_storage.js:24:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
-
app/scripts/views/sign_up.js:173:
document.cookie = 'tooyoung=1;';
-
app/tests/spec/views/sign_up.js:53:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
-
app/tests/spec/views/sign_up.js:76:
document.cookie = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
Something like TOO_YOUNG_COOKIE = 'tooyoung=1; expires=Thu, 01-Jan-1970 00:00:01 GMT';
in /app/scripts/lib/constants.js and then in the src we could just use it as document.cookie = Constants.TOO_YOUNG_COOKIE;
(or whatever).
[200, { 'Content-Type': 'application/json' }, JSON.stringify({ verfied: false })]); | ||
|
||
var nowYear = (new Date()).getFullYear(); | ||
fillOutSignUp(email, 'password', { year: nowYear - 14, context: view }); |
pdehaan
Aug 29, 2014
Contributor
This also strikes me as a bit weird (all this nowYear - 14
and nowYear - 13
business in each test).
Not sure if we want to do this as constants at the top of the file or something. I counted 10 instances of var nowYear
in this file alone.
(Probably out of the scope of this PR, but the eyes see what the eyes see.)
This also strikes me as a bit weird (all this nowYear - 14
and nowYear - 13
business in each test).
Not sure if we want to do this as constants at the top of the file or something. I counted 10 instances of var nowYear
in this file alone.
(Probably out of the scope of this PR, but the eyes see what the eyes see.)
2181d6d
to
dabf10e
@@ -110,10 +115,26 @@ function ( | |||
}, | |||
|
|||
initializeRelier: function () { | |||
this._relier = new Relier(); | |||
this._relier = new Relier({ |
shane-tomlinson
Sep 8, 2014
Author
Member
Perhaps we should be able to pass in both a Relier and a Broker on object creation for testing.
Perhaps we should be able to pass in both a Relier and a Broker on object creation for testing.
this._window = options.window || window; | ||
|
||
this._channel = new FxDesktopChannel(); | ||
this._channel.init({ |
shane-tomlinson
Sep 8, 2014
Author
Member
Probably not for this PR, but I'm starting to be confused by a mixture of startup paradigms. In some places our objects use init
, in others initialize
. When an object follows the Backbone conventions, it uses initialize
and configuration is passed to the constructor instead of in a separate call to init.
init
is my fault. We should probably standardize on initialize
to make our lives easier.
Probably not for this PR, but I'm starting to be confused by a mixture of startup paradigms. In some places our objects use init
, in others initialize
. When an object follows the Backbone conventions, it uses initialize
and configuration is passed to the constructor instead of in a separate call to init.
init
is my fault. We should probably standardize on initialize
to make our lives easier.
Do we need to tweak the PR title for the benefit of our changelog? |
@pdehaan - ya. I'll do that once we move a bit further through this. |
Remaining work:
|
|
||
'use strict'; | ||
|
||
define([ |
shane-tomlinson
Sep 15, 2014
Author
Member
This isn't used yet, so get rid of it.
This isn't used yet, so get rid of it.
}, | ||
|
||
_isForceAuth: function () { | ||
// XXX is this the correct place for this? |
nchapman
Sep 17, 2014
Contributor
It probably depends where all we need to answer this question. If it's only in this module, then this is probably fine, but it seems like we might need to answer the same question in different contexts.
It probably depends where all we need to answer this question. If it's only in this module, then this is probably fine, but it seems like we might need to answer the same question in different contexts.
|
||
_isForceAuth: function () { | ||
// XXX is this the correct place for this? | ||
return this._window.location.pathname === '/force_auth'; |
nchapman
Sep 17, 2014
Contributor
I'm thinking it would be nice to figure out what kinds of data Brokers need and pass those into the constructor instead of it having to reach into window
for random bits of data.
I'm thinking it would be nice to figure out what kinds of data Brokers need and pass those into the constructor instead of it having to reach into window
for random bits of data.
Session.clear(); | ||
// XXX does this go here, or into the Relier? | ||
// forceAuth is only used for the FxDesktop Sync flow. | ||
Session.set('forceAuth', true); |
nchapman
Sep 17, 2014
Contributor
What ends up consuming this from the Session
?. It would be ideal if the consumer could query the Broker
directly.
What ends up consuming this from the Session
?. It would be ideal if the consumer could query the Broker
directly.
/** | ||
* Transform the signin/signup links if necessary | ||
*/ | ||
transformLink: function (link) { |
ckarlof
Oct 30, 2014
Contributor
I prefer decorate vs transform here, personally.
I prefer decorate vs transform here, personally.
@shane-tomlinson, this needs a rebase. It's looking good. I ideally want to finishing reviewing this tomorrow, but I have meetings from 9am-5pm. I hopefully can get to it at 5pm. Otherwise, I'll fight to reclaim time! Friday I'm off, so I hope this doesn't drag on to next week. |
b4b0292
to
be2bd87
submit: function () { | ||
var self = this; | ||
return p().then(function () { | ||
if (self.isOAuthSameBrowser()) { |
shane-tomlinson
Oct 30, 2014
Author
Member
Check whether the Loop flow should finish the OAuth flow in the verification tab if the user closes/replaces the original tab. If so, we may need to re-introduce the afterSignUpVerified
and afterResetPasswordVerified
(or similar) functions to the brokers and let the brokers coordinate as they see fit.
Check whether the Loop flow should finish the OAuth flow in the verification tab if the user closes/replaces the original tab. If so, we may need to re-introduce the afterSignUpVerified
and afterResetPasswordVerified
(or similar) functions to the brokers and let the brokers coordinate as they see fit.
…up, closes original tab, and opens the verification link in the same browser. This is to add additional coverage to prepare for the add-a-broker branch. Additional work: * Reduce duplication in the web channel tests by calling the fillOutSignUp and fillOutSignIn FunctionalHelpers.
…mplete password reset forms.
* Start to add brokers that know how to startup/complete flows. * 5 brokers to start, base, oauth, fx-desktop, redirect, web-channel. * Get rid of the Channels high level abstraction, these are used directly by the brokers if needed. * Move some code from service-mixin and various channels to brokers. * Update tests to make use of the brokers. * No longer save forceEmail to Session, get it from the relier. * Remove the `signIn` from `completeResetPassword` in the FxaClient, this is now done in the views. * No longer call `signIn` from `changePassword` in the FxaClient, this is now handled by the views. This allows the signature of `changePassword` to be much smaller. * Move the re-link check from fxa-client to the views to allow finer grained control over when they are presented. * Remove Session.forceAuth handling from fxa-client.js, this is now stored in relier.email * Create a search-params mixin in models/mixins. * Migrate signin/signup/verification finishing code from service-mixin to the brokers so each broker can do their own thing. * Really shrink service-mixin to a bare bare minimum, fix the unit tests, make sure all the current functional tests pass. * Extract a ChannelMixin for use by the brokers.
…ow sends OAuth credentials after the reset password is complete when the original tab is closed. fixes #1825
* | ||
* @return {promise} | ||
*/ | ||
afterResetPasswordConfirmationPoll: function () { |
* | ||
* @return {promise} | ||
*/ | ||
afterSignUpConfirmationPoll: function () { |
* | ||
* @return {promise} | ||
*/ | ||
afterCompleteSignUp: function () { |
* | ||
* @return {promise} | ||
*/ | ||
afterCompleteResetPassword: function () { |
ckarlof
Nov 4, 2014
Contributor
Maybe not because it usually does nothing, except for the WebChannel flow, in which case, it finishes the OAuth flow. Let's keep it.
Maybe not because it usually does nothing, except for the WebChannel flow, in which case, it finishes the OAuth flow. Let's keep it.
oAuthClient: options.oAuthClient | ||
}); | ||
}, | ||
|
||
afterRender: function () { |
ckarlof
Nov 4, 2014
Contributor
Wow, these two oauth views are looking pretty slim. Do we have them just to call this.setupOAuthLinks()
?
Wow, these two oauth views are looking pretty slim. Do we have them just to call this.setupOAuthLinks()
?
client = new FxaClientWrapper({ | ||
channel: channelMock | ||
}); | ||
client = new FxaClientWrapper(); |
ckarlof
Nov 4, 2014
Contributor
nice! terrible mixing of concerns previously.
nice! terrible mixing of concerns previously.
@shane-tomlinson, I have a few final comments, and I created issues for those that could be addressed after the initial merge. INCOMING! |
This is for @nchapman, @zaach, @vladikoff and @ckarlof. These are the first brokers, see what you think!
feat(client): Add some brokers!