How to make CORS work?

I am trying to get CORS working with TeamCity but running into all manner of problems. I'm using JQuery in a file served from a local Apache server making REST queries against a TeamCity server which also happens to be local (for the sake of testing), but will eventually be remote.

Even so, I get CORS errors.

In TeamCity, the internal properties show up as
rest.cors.origins=myserver.com

Yet, when I make a request for json, I get an error like
XMLHttpRequest cannot load http://myserver.com:8111/httpAuth/app/rest/builds/?locator=count:10. Origin http://myserver.com is not allowed by Access-Control-Allow-Origin

This request is being made in JQuery GET but is coming through the browser as OPTIONS (because of cors preflight - and here, I'm not sure if it's Chrome, JQuery, or TC where I need to fix things)

If I make the request without the accepts header or an authorization header, the request is an expected GET but fails because of authorization. Using a URL like http://user:pass@myserver.com doesn't work. Nor does JQuery's username/password get successful authorization.

So, I changed things around, I used jsonp with a callback. This actually worked but is returning XML - the application/json header is ignored because of the way jsonp is executed (via an injected SCRIPT block). Is there a way to specify json in the REST URL rather than relying solely on the Accept header?

Any advice or sample code of using CORS correctly to make requests?

5 comments
Comment actions Permalink

Hi Andy,

With the authentication on OPTIONS requests, there is a known issue, but it should wirk fine in Chrome which supported authentication in OPTIONS requests last time I checked.

Not sure what you mean by jasonp requests as there is no support for those in TeamCity yet.

> Is there a way to specify json in the REST URL rather than relying solely on the Accept header?

By chance there is. You can add the URL parameter "?overrideAccept=application/json" to any request to override Accepts header. However, this is not a "documented feature" and can/will be changed in the future versions.


As CORS is not a simple topic and can be full of surprises, I'd recommend to do the CORS and TeamCity parts separately in order to isolate issues a bit. Once you get the code work with some simple CORS-enabled service (e.g. your own), you can try the same with TeamCity.

Anyway, any feedback on the REST API and it's CORS functioning is welcome!

Out of curiosity, what kind of application are you writing?

0
Comment actions Permalink

Thank you for the feedback. I'll have to do some more digging around this. There's a couple things that I'm trying to do with the REST API: 1) collect screenshot artifacts from recent builds into a page that's easier to work with; 2) review all builds by branch (which afaik is not possible in the web UI - you have to go project by project and filter on branches there)

It's possible these things would be better done with a plugin but it seemed like it'd be easier to work with JS and HTML than Java, an unfamiliar API, and a longer build cycle than refreshing a web page.

0
Comment actions Permalink

Andy,

OK, sounds good.

Some small comments:
> 1)  collect screenshot artifacts from recent builds into a page that's  easier to work with;

You might also consider publishing an HTML page in the build artifacts with the screenshots embedded/linked. THe page can then be displayed as a report tab.

> 2) review all builds by branch (which afaik is not  possible in the web UI - you have to go project by project and filter on  branches there)

Do you mean you need a list of all builds on a specific branch across all the build configurations in some project? Indeed, there is no view like this now (other then project's change log filtered by branch with builds displayed).
What questions should the presentation answer? How would you want the list to be ordered if not by the build configuration?

0
Comment actions Permalink

Yes - we have lots of different projects that can be triggered by changes in git to our server-side code. When we work on a server-side feature branch, those runs are spread across projects but it would be nice to be able to see a page that is all the builds run against a specific branch. That's the sort of thing we're looking for. So, it would be like seeing all the branches running under a configuration, but different axis of organization - all the configurations running against a specific branch.

0
Comment actions Permalink

Andy,

Thank you for the details.
Still not quite sure why branch filter on the project page does not address the need.
However, that's probbaly way too off the original topic of the thread, so we can put this off till some other discussion...

0

Please sign in to leave a comment.