Allow UI to query client directly for task logs/state

[notnoop]

Nomad web UI currently fails when querying client nodes for allocation
state end endpoints, due to CORS policy.

The issue is that CORS requests that are marked withCredentials need
the http server to include a Access-Control-Allow-Credentials [1].

But Nomad Task Logs and filesystem requests include authenticating
information and thus marked with credentials=true[2][3].

It's worth noting that the browser currently sends credentials and
authentication token to servers anyway; it's just that the response is
not made available to caller nomad ui javascript. For task logs
specifically, nomad ui retries again by querying the web ui address
(typically pointing to a nomad server) which will forward the request
to the nomad client agent appropriately.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials
[2]

nomad/ui/app/components/task-log.js

Line 50 in 101d037

RSVP.race([this.token.authorizedRequest(url), timeout(timing)]).then(

[3]

nomad/ui/app/services/token.js

Lines 25 to 39 in 101d037

	// All non Ember Data requests should go through authorizedRequest.
	// However, the request that gets regions falls into that category.
	// This authorizedRawRequest is necessary in order to fetch data
	// with the guarantee of a token but without the automatic region
	// param since the region cannot be known at this point.
	authorizedRawRequest(url, options = { credentials: 'include' }) {
	const headers = {};
	const token = this.secret;
	if (token) {
	headers['X-Nomad-Token'] = token;
	}
	return fetch(url, assign(options, { headers }));
	},

[DingoEatingFuzz]

I'm sure this is a good patch and it works as described, but it's puzzling to me. I swear @schmichael and I worked through this when we put CORS in place originally. Alas I don't remember any of that pairing session.

Maybe @schmichael does?

[notnoop]

Looks like there was a regression. CORS code was added in October 2017 without setting credentials flag in #3414 and #3416. I suspect we broke it incidentally when we added the credentials="include" flag got set later in #3728 in January 2018.

[backspace]

Is it possible to have a test assertion that this header exists, to prevent a regression happening again?

[notnoop]

@backspace What would you suggest? Is there a way to have mirage or frontend tests assert that browsers load the page given those headers?

I feel like adding a backend test simply asserting which headers are set isn't quite meaningful and wouldn't have caught the regression here considering its due to ui changing the request parameters? IMO, an effective test would be probably an integration or an e2e test, but we lack this class of tests now.

[DingoEatingFuzz]

I think this is safe to merge. It would be super cool to do a UI e2e test, but that's not realistic at the moment.

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.