Keep getting "request blocked" at login

Ryan Kelly rfkelly at
Tue Jun 28 05:30:51 UTC 2016

On 28/06/2016 04:54, Gabriel Ivașcu wrote:
> On Mon, Jun 27, 2016 at 3:37 AM, Ryan Kelly <rfkelly at> wrote:
>>> Will these features be documented somewhere? I'm interested in how the
>>> client flow should work.
>> They will be documented, as they come online, most likely as part of our
>> API documentation here:
>> However, we're going to try to move away from having FxA consumers
>> directly access this API, and move towards a more traditional OAuth flow
>> that uses this API under the hood.
> Does this mean that the protocol here [0] won't be available for
> general public use any longer?

It is my intention to deprecate that protocol for general public use,
yes.  There is no particular plan or timeline for doing so, but it's
something I want to work towards.

Naturally we can only really do that if we replace it with something better.

>> If you're working on integrating FxA/Sync with something specific, I'd
>> love to hear more about it so that we can feed your use-case into our
>> longer-term plans.
> I am currently working on my Google Summer of Code project aiming to
> introduce a bookmarks sync feature for GNOME's browser, Epiphany,
> allowing users to sync data with Firefox with only using a Firefox
> Account. Part of my project implies implementing the client side of
> the onepw protocol in Epiphany in order to fetch the sync keys used to
> encrypt/decrypt synchronized data records. You can find more details
> about my project here [1].
> Yet, I'm afraid I can't proceed with my project if the server answers
> me with "Request blocked" when calling the login endpoint, that being
> the reason I asked for answers on this list in the first place.

Ah, interesting.  I would suggest you do this via what we call the
"webchannel flow", which is a way for the browser to delegate some of
the UI and signin logic to web content.  It's how Firefox, Firefox for
Android and Firefox for iOS all do login with FxA.

The documentation for this is tucked away in github here:

But the idea is that you:

* Create an iframe and load FxA with some query parameters to specify
the flow you want:

* Listen for custom "WebChannelMessageToChrome" events from this iframe.
 Since this is a custom event, only the browser itself can listen for
such events.

* Let the user login through the web content in the iframe, and it will
send a "fxaccounts:login" message with the credentials when the login is

I understand you may not have time to change your approach at this stage
in the project, but if possible, this approach would be significantly
more robust to any future enhancements we make to the FxA login flow.

> Also, I've read in your email from the other day that you are going to
> introduce a sign-in confirmation email feature. How soon will this
> happen?

Within weeks.  Don't worry though, we had to design the first version of
it to be backwards-compatible with the code in currently shipping
versions of Firefox, Firefox for Android, and FirefoxOS.  So you should
find that it works more-or-less transparently to what you have so far.



More information about the Sync-dev mailing list