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

VERIFIED FIXED

Status

defect
VERIFIED FIXED
8 years ago
5 years ago

People

(Reporter: philikon, Assigned: rfkelly)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa?])

Attachments

(3 attachments, 2 obsolete attachments)

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.
Whiteboard: [qa?]
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.
Summary: Infer fallback_node from the Host header or return 404 for node/weave in default config → Infer fallback_node from the Host header or require it to be set if node assignment is not configured.
Assignee

Updated

7 years ago
Assignee: nobody → rfkelly
Assignee

Comment 2

7 years ago
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.
Attachment #625063 - Flags: review?(telliott)
Assignee

Comment 3

7 years ago
For good measure, comment-out and document fallback_node in the various example config files.
Attachment #625066 - Flags: review?(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.
Assignee

Comment 5

7 years ago
Erm, got my wires crossed when commenting-out fallback_node in the config files, this new patch keeps it in the correct section.
Attachment #625066 - Attachment is obsolete: true
Attachment #625066 - Flags: review?(telliott)
Assignee

Comment 6

7 years ago
Might be safer just to fail out with a helpful error if no fallback_node is specified?
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%
Attachment #625063 - Flags: review?(telliott) → review-
Assignee

Comment 8

7 years ago
OK, updated patch to return a 503 if no fallback node has been configured.
Attachment #625063 - Attachment is obsolete: true
Attachment #626707 - Flags: review?(telliott)
Assignee

Comment 9

7 years ago
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.
Attachment #626708 - Flags: review?(telliott)
Attachment #626707 - Flags: review?(telliott) → review+
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.
Attachment #626708 - Flags: review?(telliott) → review+
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee

Comment 13

6 years ago
> 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.
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago5 years ago
Resolution: --- → FIXED
OK.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.