CORS support in barracuda

Thanks for the quick response.

I just tried breaking the add_header directive out of the if statement, like so.

###
### Catch all unspecified requests.
###
location / {

  add_header Access-Control-Allow-Origin *; # <- OUTSIDE OF THE IF



  if ( $http_user_agent ~* wget ) {
    return 444;
  }
  try_files $uri @cache;

    # For CORS
    #if ($request_method = OPTIONS ) {
    #  add_header Access-Control-Allow-Origin "http://localhost"; # <- needs to be updated
    #  add_header Access-Control-Allow-Methods "POST, GET, OPTIONS";
    #  add_header Access-Control-Allow-Headers "Authorization";   # <- You may not need this...it's for Basic Auth
    #  add_header Access-Control-Allow-Credentials "true";        # <- Basic Auth stuff, again
    #  add_header Content-Length 0;
    #  add_header Content-Type text/plain;
    #  return 200;
    #}

}

Unfortunately I cannot get it to work. Just to be clear, I saw that /var/aegir/config/includes/nginx_modern_include.conf was being included in all of my vhosts, so that is where I am putting it. After ever save of that nginx_modern_include.conf file, I am doing an nginx reload, stop, and start.

But no matter what I try, this is the error from Chrome:
XMLHttpRequest cannot load http://domain.tld/wineries/system/connect.jsonp. Origin http://localhost is not allowed by Access-Control-Allow-Origin.

Is there somewhere else I need to be putting this for each vhost as well, since that is a global file? Is there any other place it could be being overridden?

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 11 Apr 2012 20:31:07 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
X-Backend: A
X-Purge-Level: none
X-Accel-Expires: 10800
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Last-Modified: Wed, 11 Apr 2012 20:31:07 +0000
Cache-Control: no-cache
ETag: "1334176267"
X-Engine: Barracuda 1.0 ET
X-Device: normal
X-Speed-Cache: BYPASS
X-Speed-Cache-Expire: 3h
X-NoCache: Skip
X-GeoIP-Country-Code: US
X-GeoIP-Country-Name: United States

Although the result in two different browsers is the same error... Returns 301 w/ "Origin http://localhost is not allowed by Access-Control-Allow-Origin"

I looked through that other ticket. It would seem that my OPTIONS method is being blocked by something. However, I see exactly where you guys are doing that in the nginx config. I added OPTIONS as an allowed method.

I'm completely baffled at this point. It must be being overridden somewhere. My experience with nginx is literally this server. So I'm pretty fresh. I knew Apache well enough to get this solved a long time ago.

No dice.

I was looking at the different config files... modern, advanced, compact.

Is the add_header option smart enough to know if I add the same headers twice, to only include it once? Or is it truly split by each location *?

I think I got it!

Add OPTIONS to the allowed request methods...

###
### Deny not compatible request methods without 405 response.
###
if ( $request_method !~ ^(?:GET|HEAD|POST|OPTIONS)$ ) {
  return 444;
}

And then in the /index.php section (I still can't figure out why it needs to be added here, I tried almost every relevant section and this was the only one that worked.)

###
### Send all non-static requests to php-fpm, restricted to known php file.
###
location = /index.php {
  add_header    X-Engine "Barracuda 1.0 ET";
  add_header    X-Device "$device";
  add_header    X-Speed-Cache "$upstream_cache_status";
  add_header    X-Speed-Cache-Expire "$will_expire_in";
  add_header    X-Speed-Cache-UID "$cache_uid";
  add_header    X-NoCache "$nocache_details";
  add_header    X-GeoIP-Country-Code "$geoip_country_code";
  add_header    X-GeoIP-Country-Name "$geoip_country_name";
  add_header    X-This-Proto "$http_x_forwarded_proto";

  ### Modification for CORS
     add_header Access-Control-Allow-Origin *;
     add_header Access-Control-Allow-Methods "POST, GET, OPTIONS";
     add_header Access-Control-Allow-Headers "X-Requested-With";

  ###
  ### Use Nginx cache for all visitors.
  ###
  set $nocache "";
  if ( $nocache_details ~ (?:OctopusNCookie|Args|Skip) ) {
    set $nocache "NoCache";
  }

Now, after all of this, I still don't think this is the "right" way to do it. There is no reason it should be in the index.php section. At least with the way I am thinking of it, it should be in the ~* section and also something would have to change in the section where you control "system" paths because the services module uses /servicename/system/ for connections.

Any thoughts?

I actually made a patch against STABLE for it. Although I'm unsure if anything has changed in HEAD.

Here is the patch that adds OPTIONS as an allowed request method (I think that should be on by default, but its up to you) and the header for origin and the "X-Requested-With" in the right section. Those are commented out by default, because after thinking about it, its obviously not a good idea to turn on cross-origin requests by default. The X-Requested-With flag is there because, if they are turning on CORS, there is a 99% change they are going to need and use X-Requested-With. Especially since I've heard chatter of Mozilla requiring it soon.

I'm not sure about your comment styles... I tried to match them. Hope this helps.

No they don't always end with .jsonp. In fact, even among the services module they can have multiple different ways of formatting the url.

Also, another HUGE problem. My patch above is worthless in multiple ways. Not only is it not formatted right, but it doesn't even work. Something was going on the day I tested it, and it seemed to be spitting out jsonp the way I needed it to. But I found out that it wasn't the case. In the services module, when I enable the rest server, I still get a screwed up return error saying that Origin http://localhost is not allowed by Access-Control-Allow-Origin. So I'm back to square one.

I will continue to mess with it, but for now, I'm going to change the development environment for this app so I can at least continue working on it and do not have to wait to enable CORS.

At this point, I've added the config options to just about every spot in that nginx_modern_config. And its simply not working. I am open to ideas, but I feel kind of like it is being overwritten or blocked somewhere else.

Just throwing this out there. It may be a bad idea so fire away if so. But I was thinking about this, and a few other configuration options that I needed to change specific to the services api in drupal (I am running into some issues with nginx caching json responses with services api... yeah I know it doesn't make sense but it seems to be happening). But most of these changes really don't need to be on by default, for security's sake.

So what if I made a stand-alone module, or forked provision/barracuda, that would allow you to turn these options on on a per-site basis while, well, provisioning them. That, or at least some functionality for the entire platform to adjust the settings accordingly. Even if it was platform specific, and we just had an installation profile for it.

Maybe I'm wrong, but I see more and more use for cross-origin requests, and usable services api with these mobile apps and even new html5 specs (we already saw it with IE and fonts). I don't think that every site you provision on aegir needs to have these options, but it would be a nice thing to have when you are using octopus to slam out a bunch of instances and platforms that will be doing advanced ajax and cross-origin stuff.

Just an idea... As always, I'm more worried about where to put it than how to implement it.