692355 - Infer fallback_node from the Host header or require it to be set if node assignment is not configured.

Status: VERIFIED FIXED

(Cloud Services :: Server: Registration, defect)

Description

[Philipp von Weitershausen [:philikon]]

The most frequent problem that people who set up their own Sync server run into is that they forget to set fallback_node.

I would recommend that in the default configuration of the reg server, we either infer this value from the Host HTTP header on the node/weave call, or we return 404 like the good old minimal Weave server. The client specifically knows how to handle a 404 call on node/weave for that very reason.

Comment 1

[Mike Connor [:mconnor]]

At the least, we should enforce this setting if node assignment isn't configured.  If we can safely infer, great.

404 is speced as "user not found" in the API docs, so not all clients necessarily handle that response like the desktop client.

Comment 2

[Ryan Kelly [:rfkelly]]

Attachment: patch to infer fallback node if none configured

This patch changes the behavior to return request.host_url rather than the special string "null".  This seems to work in a variety of common hosting situations, and should hard fail in others (e.g. behind a reverse proxy that rewrites the Host header).

The docs already contain a warning that you must configure fallback_node if hosting behind a proxy.

Comment 3

[Ryan Kelly [:rfkelly]]

Attachment: patch to comment-out fallback_node in config files

For good measure, comment-out and document fallback_node in the various example config files.

Comment 4

[Toby Elliott [:telliott]]

I dunno. This seems a little dangerous in localhost situations with proxies, and I'm not sure that it might not silently cause more errors. I need to think about this for a bit, as it's potentially dangerous.

Comment 5

[Ryan Kelly [:rfkelly]]

Attachment: patch to comment-out fallback_node in config files

Erm, got my wires crossed when commenting-out fallback_node in the config files, this new patch keeps it in the correct section.

Comment 6

[Ryan Kelly [:rfkelly]]

Might be safer just to fail out with a helpful error if no fallback_node is specified?

Comment 7

[Toby Elliott [:telliott]]

Comment on attachment 625063 [details] [diff] [review]
patch to infer fallback node if none configured

Yeah, I'd prefer a 503 if there's no fallback node defined (and for goodness sake, make sure the default value is blank!)

Ultimately, the reason comes down to the idea that if we do encounter a situation where the host inference is wrong for whatever reason, diagnosing and fixing the problem is really hard. The errors are cryptic, contained in the client and don't suggest the root of the problem. So while it might work for 95%, forcing the user to define a node will work for 100%

Comment 8

[Ryan Kelly [:rfkelly]]

Attachment: patch to give 503 if not fallback node is configured

OK, updated patch to return a 503 if no fallback node has been configured.

Comment 9

[Ryan Kelly [:rfkelly]]

Attachment: docs patch to explain that fallback_node must be set

Adding some docs to explain that you have to set nodes.fallback_node for all installations.  Combined with the existing patch to comment it out in all example config files, this should give users enough guidance to understand the situation.

Comment 10

[Toby Elliott [:telliott]]

Comment on attachment 626708 [details] [diff] [review]
docs patch to explain that fallback_node must be set

Looks good. Hard to miss this problem now.

Comment 11

[Ryan Kelly [:rfkelly]]

http://hg.mozilla.org/services/server-reg/rev/3165dab7965c

http://hg.mozilla.org/services/server-full/rev/448e4500f2e4

https://github.com/mozilla-services/docs/commit/8921a36dfc4a5f5e384ca8d995997b98e6efd5d6

Comment 12

[Toby Elliott [:telliott]]

With the possible 1.5 release, I think we should revisit this. The current solution still isn't working - fallback node is constantly tripping up users who try to install their own server, and the client result is no less cryptic and no harder to diagnose if you turn on logging.

I think Phillip had it close to right in the original post. fallback_node should be empty by default in the config. If it isn't set, use the host header and any prefix in the path. An explicit value of null can be used for "do not fall back"

For most users, that'll work right out of the box. A few will break, but checking their URLs in logging will make it pretty clear what's happening.

Comment 13

[Ryan Kelly [:rfkelly]]

> With the possible 1.5 release, 

It's complicated there too.  In the new FxA-consuming world the node allocation is done by tokenserver.  Since tokenserver consumes BrowserID assertions, it needs to be explicitly told what audiences it should accept.  It *cannot* infer this from the Host header as that's a security risk.

I'm not sure whether it would be more sensible to use the Host header or the configured BrowserID audience as the default node.

Comment 14

[Toby Elliott [:telliott]]

Decisions for how to configure the fallback node have been made and implemented for 1.5. We may revisit this in the future, but I think we can set it aside at this point.

Comment 15

[James Bonacci [:jbonacci]]

OK.