Keep getting "request blocked" at login

Gabriel Ivașcu ivascu.gabriel59 at gmail.com
Thu Jun 30 22:26:16 UTC 2016


On Thu, Jun 30, 2016 at 7:56 PM, Nicholas Alexander
<nalexander at mozilla.com> wrote:
> Hi Gabriel,
>
> The "whole code need[s] to be rewritten", but it's really not as bad as it
> looks.  The WebChannel stuff is just some browser-level abstraction around a
> simple event passing model, and in fact you can opt out of it entirely (at
> least for a while).  There's an example of doing the dance in a WebView in
> the iOS repository.  You can start digging into the code at
>
> https://github.com/mozilla/firefox-ios/blob/5238e873e77e9ad3e699f926d12f61ccafabdc11/Account/FirefoxAccountConfiguration.swift#L95
>
> and
>
> https://github.com/mozilla/firefox-ios/blob/5238e873e77e9ad3e699f926d12f61ccafabdc11/FxAClient/Frontend/SignIn/FxASignIn.js
>
> and
>
> https://github.com/mozilla/firefox-ios/blob/e8f885d0f169f55dd466838a09ba0a440b6bc83c/FxAClient/Frontend/SignIn/FxAContentViewController.swift#L20.
>
> The first link includes `service=sync&context=fx_ios_v1`; that'll ensure the
> accounts service sends you the messages over postMessage.  The second link
> shows how to inject the message listener into the WebView context, so you
> can react to the messages.  The third link shows what we do with those
> messages -- the important one is "login", which includes all the tokens
> you'll need to talk to the auth server to get keys, etc.
>
> This postMessage interface has been cleaned up and regularized into the
> WebChannel interface, but the underlying mechanism is almost identical.  The
> browser bits are just an abstraction on top of that since we want to use the
> same approach for many browser <-> content interactions.

Thanks Nick, I'll give it a look tomorrow, now it is really late here.

Regards,
Gabriel


More information about the Sync-dev mailing list