Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(oauth): support Fenix WebChannels #2320

Merged
merged 1 commit into from
Sep 5, 2019

Conversation

vladikoff
Copy link
Contributor

@vladikoff vladikoff commented Aug 26, 2019

@vladikoff vladikoff force-pushed the feature.fenix-channel-clean branch 4 times, most recently from 8ee8749 to 4fb0a6d Compare August 29, 2019 23:09
@vladikoff vladikoff marked this pull request as ready for review August 29, 2019 23:09
@vladikoff
Copy link
Contributor Author

@shane-tomlinson @rfk @vbudhram I'm finishing up the tests for this, but please take a look at the non-test code. We scoped it down with Grisha, and seems like there are not as many changes as anticipated for the v1 of this

Copy link
Contributor

@rfk rfk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like there are not as many changes as anticipated for the v1 of this

This is indeed a smaller change than I was expecting, 👍!

It all makes sense to me, and I left only nits below. But I don't feel like the right person to give this an explicit r+.

As I mentioned briefly in Portland, I think the use of a single "broker" abstraction is starting to strain a little bit here, and the fact that we need separate "oauth webchannel broker" and "pairing supplicant webchannel broker" models is a symptom of that. I suspect there are two related but distinct abstractions in play here, once which controls the kind of flow being performed (a pairing supplicant flow) and another which controls how the results of that flow are communicated out (via oauth webchannels).

It'd be nice to be able to decompose those, but that's a way bigger refactor than justified by this PR. Also it's something that @shane-tomlinson will likely have much better-informed opinions on that I do 😄.

});

return channel;
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it's worth some sort of WebChannelMixin that could provide shared implementations of this logic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 - seems like a great suggestion to minimize duplication.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now as easy as other methods, I filed a follow up for this #2406

const supportedEngines =
response.capabilities && response.capabilities.engines;
if (supportedEngines) {
// supportedEngines override the defaults
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a subtle change in behaviour from the desktop broker, I think it would be worth calling out more explicitly in e.g. the new protocol doc for the oauth-webchannel broker.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So Fenix passes back all of the engines it supports and there are no defaults?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Thought I answered this somewhere already) Yes, the native app like Fenix will send in the engines in supports

packages/fxa-content-server/server/lib/configuration.js Outdated Show resolved Hide resolved
Copy link
Contributor

@vbudhram vbudhram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladikoff This looks 👍🏽 to me, I don't really have any objections with the approach here.

},

getCommand(commandName) {
if (!this.commands) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this ever be undefined and throw?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah some brokers can have this be undefined

as part of the [firefox-accounts](https://github.com/mozilla-mobile/android-components/blob/master/components/service/firefox-accounts/README.md) Android component.

```
* Communication channel is established from web content to this class via webextension, as follows:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was helpful 👍🏽

Copy link
Contributor

@shane-tomlinson shane-tomlinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall approach looks good, and the PR is definitely moving in the right direction. I left a bunch of questions/suggestions/possible simplifications, I don't think anything too major.

});

return channel;
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 - seems like a great suggestion to minimize duplication.

const supportedEngines =
response.capabilities && response.capabilities.engines;
if (supportedEngines) {
// supportedEngines override the defaults
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So Fenix passes back all of the engines it supports and there are no defaults?

* [fxa-web-content] <--js events--> [fxawebchannel.js webextension] <--port messages--> [WebChannelFeature]
*
* [fxa-web-channel] [WebChannelFeature] Notes:
* fxa-status ------> | web content requests account status & device capabilities
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need/want to document fxaccounts:can_link_account?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we are dropping that for now

.then(
openFxaFromRp('signup', {
query: {
context: 'oauth_webchannel_v1',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer need ?service=sync? Wow


// switch to the original window
.then(closeCurrentWindow())
.then(testIsBrowserNotified('fxaccounts:oauth_login'))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to test for an expected screen here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not here, for now we take over on login

Copy link
Contributor Author

@vladikoff vladikoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@vladikoff vladikoff changed the base branch from master to train-145 September 4, 2019 19:53
@vladikoff vladikoff force-pushed the feature.fenix-channel-clean branch from 56971a5 to 5523dbf Compare September 4, 2019 19:56
@vladikoff
Copy link
Contributor Author

@shane-tomlinson we landed the client part in mozilla-mobile/android-components#4221 , I've rebased this PR against train-145. Re-Requested review, let me know!

@vladikoff vladikoff force-pushed the feature.fenix-channel-clean branch 2 times, most recently from 4dc790f to b67f200 Compare September 4, 2019 20:46
Copy link
Contributor

@shane-tomlinson shane-tomlinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+ - looks great. There is one var that could be a const, and one initialize method that doesn't seem to be needed, plus you might want to add functional tests for the email first flow if those are used by Fenix.

@@ -345,7 +354,10 @@ export default BaseAuthenticationBroker.extend({
this.clearOriginalTabMarker();
return this.getOAuthResult(account).then(result => {
result = _.extend(result, additionalResultData);
return this.sendOAuthResultToRelier(result);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way you reordered the metrics flush and sending the result to the relier makes much more sense. 👍

*/
sendOAuthResultToRelier(result, account) {
result.redirect = Constants.OAUTH_WEBCHANNEL_REDIRECT;
if (account && account.get('declinedSyncEngines')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

);
},
tests: {
signup: function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Fenix make use of the email first flow? If so, should probably test that too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants