1014836 - Please add treeherder to allowed origins response headers for BuildAPI self-serve

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Cameron Dawson [:camd]]

when re-triggering or cancelling jobs in tbpl, it returns two response headers from the POST:

Access-Control-Allow-Origin: https://tbpl.mozilla.org
1:30 PM <camd> Access-Control-Allow-Credentials: true

Would you please return those headers for treeherder as well?  Treeherder is the upcoming replacement for tbpl.  

We would need it for:

treeherder.mozilla.org
treeherder.allizom.org
treeherder-dev.allizom.org

and can you do it for local instances, too?
local.treeherder.mozilla.org

Thanks!

Comment 1

[Cameron Dawson [:camd]]

not sure if it matters, but I'm using the endpoint: POST https://secure.pub.build.mozilla.org/buildapi/self-serve/try/request

Comment 2

[Ed Morley [:emorley]]

Ah this explains bug 911504.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

I'm not sure where this lives these days, it's not in our current puppet repo. The old location was
 http://mxr.mozilla.org/build/source/puppet-manifests/modules/buildapi/templates/production.ini.erb#29

IT puppet maybe ? cc Dustin.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

It's on the releng cluster, like just about all releng websites are these days.

From there, like all sites on a cluster, its production config is in
  /data/releng/src/buildapi
and staging in
  /data/releng-stage/src/buildapi

and this particular setting is configured in production.ini.

Once you change that, run ./update to push the changes to the webheads.

For settings that appear in the Apache config, you'd need a change to infra puppet, but this doesn't happen to be such a case.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

a+ from catlee on irc, I'll get this today.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Cameron Dawson [:camd] from comment #0)
> We would need it for:
> 
> treeherder.mozilla.org
> treeherder.allizom.org
> treeherder-dev.allizom.org

Are these all https ? Apparently we specify the protocol as well as the domain.
 
> and can you do it for local instances, too?
> local.treeherder.mozilla.org

What's the justification for this one ? I'm a little wary of allowing developer instances of tree herder to interact with buildapi production.

Comment 7

[Cameron Dawson [:camd]]

yes, these will be https POSTs.

As for the question on local.treeherder: The call still works even without this change (i.e.: doing a post for a retrigger DOES do the retrigger from a local treeherder instance).  It's just that without those headers, angular can't parse the 202 response and gets a status of '0'.  So we can't tell in our callback whether it succeeded or failed, but the retrigger task has already been initiated regardless.  

So the security wouldn't be different from local/dev/stage or prod.  That being said, we don't /need/ to have it return those headers for local.  If that doesn't feel right, we can certainly skip it.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

Actually, that represents a security bug -- buildapi should not only be sending an ACAO header, but should be verifying a matching Origin header before performing the POST operation, right?  New bug?

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

How so ? AIUI the POST operation requires valid LDAP auth, regardless of where it comes from, and the CORS headers are just buildapi telling Firefox to let the web content have access to the response. Lets follow up in another bug if there's an issue here.


I've added these sites to staging and prod:
https://treeherder.mozilla.org https://treeherder.allizom.org https://treeherder-dev.allizom.org http://local.treeherder.mozilla.org
and run
  ./update 0.3.1

Production went from 0.3.0 to 0.3.1, but that should be a no-op on the server side:
 http://hg.mozilla.org/build/buildapi/pushloghtml?fromchange=113471728707&tochange=ace9bb8c2267
The agent side was already deployed (bug 1009565).