On 20/04/2015 22:35, Robin Bankhead wrote: > Quoting Ryan Kelly <[email protected]>: >>> 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.
This *should* be unrelated, it's just logging the lostname for metrics purposes. The auth checking is supposed to take the hostname from the configured publicUrl setting. >> >>> fxa-auth-server/config/dev.json >>> >> >> 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 :( The server should logs its config at startup, can you check in the log to make sure the configured value is being picked up correctly? Also, is this the same URL that you configure in the content-server settings, and that you enter as identity.fxaccounts.auth.uri in about:config? > 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 I don't think this will be relevant to your issue. > 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. Yeah, this is to be expected, it's not getting far enough along in the process to worry about trying to sync anything. > Would it help to switch to the mysql backend so I could snoop the data? This may be worthwhile, if nothing else it will mean that you can edit your account data after initial creation. > 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. IIRC you just run fxa-auth-db-mysql as a separate (internal-only) HTTP server, and ensure that the fxa-auth-server is talking to it via config options. > Are there any about:config entries on the client that I can twiddle for > more verbosity in the sync-logs? If you search for "level" in about:config you will find some, notably services.sync.log.appender.file.level. Do you have the server configured to send verification emails, and do said emails come through correctly? It may be that you're hitting a weird error path with trying to use an unverified account. If the verification loop is not succeeding, you could try switching to the mysql backend, and manually verifying your account by flipping the bit in the db by hand. Cheers, Ryan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
