Hi Ryan, thanks for the reply.
Quoting Ryan Kelly <[email protected]>:
On 14/04/2015 23:33, Robin Bankhead wrote:
I am starting to find that I can no longer add desktop clients to my
sync-1.1 server any more (I can pair them by installing an old FF
version then upgrade through newer versions, but from FF32.0 they
consistently stop syncing and try to register with FxA). I've therefore
started trying to set up a self-hosted sync-1.5 stack.
I have the syncserver (proxied behind Apache), fxa-auth-server and
fxa-content-server components all running, and after some trial and
error can get most of the way through registration using a desktop
client with a fresh profile. However email verification never quite
works -- the sync preferences tab shows the created account as
unverified (the "Verify email" button does nothing), and although this
changes after restarting the browser, sync still fails. The problem
occurs with various calls to the fxa-auth-server returning status 401,
error 109 (or 110 in some circumstances), example:
1429017392778 Sync.BrowserIDManager ERROR Background fetch for
key bundle failed:
{"details":{"code":401,"errno":109,"error":"Unauthorized","message":"Bad
mac","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format","log":[]}}
The corresponding error code from here:
https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format
Is "109: invalid request signature". At a first guess, I suspect that
there's a mis-match between what the server and client consider the
canonical public URL of the server.
OK, that could be it - I can see that the machine's canonical hostname
is being looked up, as in the stderr output there is
07:50:00.245Z INFO fxa-auth-server: (op=request.summary, code=200,
errno=0, rid=1429516200217:hazel:28144:i8pkm4wl:10029,
path=/v1/account/login, lang=en-US,en;q=0.5, t=28, uid=00, keys=true,
email=<SNIP>)
where "hazel" is the canonical name as returned by "hostname" command.
To explain further, I run multiple Apache vhosts on the machine, so
it has many hostnames which are all subdomains of example.com. The
hosts file listings are all in the format:
192.168.2.7 hazel hazel.example.com example.com
192.168.2.7 fxa fxa.example.com
That's as authoritative as the machine's own idea of its FQDN gets:
domainname returns (none), it's never needed to be set for anything
I've been up to so far. (Perhaps I should now, eh?)
DNSMasq is also running on the machine, but is not used by its
resolver (resolv.conf only has my ISP's DNS servers, since all the
local host definitions are in the hosts file).
Just mentioning all this in case anything is relevant, for example if
the code was bypassing /etc/hosts and using DNS instead, it'd get my
WAN IP rather than the LAN one above.
fxa-auth-server/config/dev.json
3c3
< "url": "http://127.0.0.1:3030";
---
"url": "https://fxa.example.com:3030";
4a5,11
"listen": {
"host": "192.168.2.7",
"port": "9900"
},
"useHttps": true,
"keyPath": "../server.key",
"certPath": "../server.crt",
7c14
< "port": 9999,
---
"port": 25,
9c16,18
< "sender": "[email protected]",
---
"sender": "[email protected]",
"user": "myusername",
"password": "mypassword",
Try setting the "publicUrl" key on this file, to tell the auth-server
what its public-facing URL is. This value should match the one you
configure in the content-server, which AFAICT from your examples should be:
"publicUrl": "https://fxa.example.com:9900";
This had no noticeable effect :(
Just noticed I have been getting the following warning when starting
the content-server, not sure if relevant:
Warning: There are more tasks than your concurrency limit. After this limit
is reached no further tasks will be run until the current tasks are
completed. You can adjust the limit in the concurrent task options
It certainly doesn't seem to be having any trouble serving up the UI,
although I notice some items are coming up 304.
Only other observation so far is that the syncserver is not getting
any requests at all during the attempts to signup, or when signup has
been "verified" (only not really). Perhaps that's to be expected,
though.
Would it help to switch to the mysql backend so I could snoop the
data? (Not aware of being able to do this with the mem backend, please
let me know if it's possible). I've been able to build and run the
fxa-auth-db-mysql package, but I'm not clear on how to make
fxa-auth-server use it.
Are there any about:config entries on the client that I can twiddle
for more verbosity in the sync-logs?
Thanks,
Robin Bankhead
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
