Can't sync with identity.sync.useOAuthForSyncToken enabled

[berezovskyi-oleksandr]

According to Bugzilla, identity.sync.useOAuthForSyncToken is enabled for Nightly users and this option brokes sync.

Once I disabled this option, sync started working.

[rfk]

Thanks for reporting this, do you get any error messages (in either your server logs or about:sync-log on the client) when this option is enabled?

[vladikoff]

Hi @berezovskyi-oleksandr ! Did you make any other changes to your about:config besides changing identity.sync.useOAuthForSyncToken?

[berezovskyi-oleksandr]

Sorry for the delay.

My current version is Firefox Nightly 80.0a1 (2020-07-04) (64-bit).
I've created a new profile for the test and will provide logs from this new account.

@vladikoff , currently identity.sync.useOAuthForSyncToken option is enabled by-default.
In order to test, I set identity.sync.tokenserver.uri to https://firefox.MY_DOMAIN.COM/token/1.0/sync/1.5 (replaced in favor of privacy; in attached logs, you will see this URL as well).

After successfull login I got pop-ups that it's OK, but in several seconds it asks me to re-login.

@rfk , I've attached logs from about:sync-log - firefox-sync.log.

I'm running syncserver in Docker and there are no logs. Only start ones:

[2020-07-06 06:27:34 +0000] [6] [INFO] Starting gunicorn 19.6.0
[2020-07-06 06:27:34 +0000] [6] [INFO] Listening at: http://0.0.0.0:5000 (6)
[2020-07-06 06:27:34 +0000] [6] [INFO] Using worker: sync
[2020-07-06 06:27:34 +0000] [11] [INFO] Booting worker with pid: 11

Docker env vars which could be helpful:

     - SYNCSERVER_PUBLIC_URL=https://firefox.MY_DOMAIN.COM
     - SYNCSERVER_BATCH_UPLOAD_ENABLED=true
     - SYNCSERVER_FORCE_WSGI_ENVIRON=true

Once I disable identity.sync.useOAuthForSyncToken - sync works. BTW, it works with default syncserver.

[vladikoff]

Thank you for the quick response! So it seems to have trouble with self-hosted instances. We shall take a look

[mike2307]

@vladikoff
Is there any update on that? Everyone who uses Firefox 80 with an own sync server is affected by that.
I spent a couple of hours until I found the solution here (#224 (comment))

[sbraz]

On the server, there are very few logs, all I see is:

DEBUG:urllib3.connectionpool:https://oauth.accounts.firefox.com:443 "GET /v1/jwks HTTP/1.1" 200 463
INFO:mozsvc.metrics:{"token.oauth.verify_failure": 1, "code": 401, "request_time": 0.1726388931274414, "remoteAddressChain": [""], "agent": "Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0", "path": "https://myserver/token/1.0/sync/1.5", "method": "GET", "tokenserver.oauth.verify": 0.17141389846801758}

[jackyzy823]

The main reason is that tokenserver (1.4.5) is too old which requires a PyFxA ( 0.7.4 found in docker but 0.7.1 in requirements.txt weird ) contains mistakes in validate jwt.
https://github.com/mozilla/PyFxA/blob/8402734a6287abd86d6411869a68a125bd6d13e6/fxa/oauth.py#L236

syncserver/requirements.txt

Lines 13 to 14 in e1aab54

	https://github.com/mozilla-services/tokenserver/archive/1.4.5.zip
	https://github.com/mozilla-services/server-syncstorage/archive/1.6.14.zip

So you need to update the requirements.txt to

https://github.com/mozilla-services/tokenserver/archive/1.5.11.zip
https://github.com/mozilla-services/server-syncstorage/archive/1.8.0.zip

and the newer version tokenserver needs more dependencies.
you may need musl-dev mysql-dev gcc if you are using alpine which is the base of the docker image mozilla/syncserver.
then pip install --upgrade --no-cache-dir -r requirements.txt
I failed to build readline which is required by tokenserver, but it may not be important. I'm also wandering why readline is required? see mozilla-services/tokenserver@f33ca50

Please 1. update syncserver 's requirements.txt 2. build new docker image. Thanks.

Update:

Force updating PyFxA==0.7.7 in Dockerfile seems a quick workaround.

[rfk]

@jackyzy823 thank you very much! I think I understand what happened here:

• On June 10th we released v0.7.4 of PyFxA with the bug you linked above.
• On July 3rd we merged an unrelated change to this repo, which triggered a build of a new docker image, which pulled in the buggy version of PyFxA.
• On July 10th we released v0.7.6 of PyFxA with a fix for the bug, but nothing triggered an updated docker image build for this repo.