Closed Bug 1014836 Opened 8 years ago Closed 8 years ago

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


(Release Engineering :: General, defect, P2)



(Not tracked)



(Reporter: camd, Assigned: nthomas)


(Keywords: buildapi, Whiteboard: [treeherder])

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

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:

and can you do it for local instances, too?

Summary: Please add treeherder to allowed origins response headers → Please add treeherder to allowed origins response headers for BuildAPI self-serve
not sure if it matters, but I'm using the endpoint: POST
Ah this explains bug 911504.
Keywords: buildapi
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [treeherder]
I'm not sure where this lives these days, it's not in our current puppet repo. The old location was

IT puppet maybe ? cc Dustin.
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
and staging in

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.
a+ from catlee on irc, I'll get this today.
Assignee: nobody → nthomas
Priority: -- → P2
(In reply to Cameron Dawson [:camd] from comment #0)
> We would need it for:

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

What's the justification for this one ? I'm a little wary of allowing developer instances of tree herder to interact with buildapi production.
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.
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?
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:
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:
The agent side was already deployed (bug 1009565).
Closed: 8 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.