At the beginning of the middleware handler, there is:

var options = settings || defaults;

Later, at several places, the options object is modified. For example:

options.headers = this.header['access-control-request-headers'];

It means that the global middleware settings object (or defaults if no settings are specified) is modified from one request to another. I think it's dangerous and a source of bugs.

http://stackoverflow.com/questions/36328085/can-t-get-cors-working-with-koa

I need this commit 6b1e002, but it is not published as a new version.

If you need, I can help to maintain this repo @evert0n :)

ctx.throw(...) does not seem to send the access control headers

What am I doing wrong?

I get a JSON parse error:

app
  .use(bodyParser())
  .use(cors({
    methods: ['GET', 'PUT', 'POST', 'PATCH', 'DELETE']
  }))

Please :-)

Hi,
I am using this lib with Typescript.
Do you plan to make a "@types/koa-cors" module? It's quite nice to have this when you're coding.

Thx

How do you get the request origin from the request object that is passed to an origin function? It seems as though this object does not contain the origin, which would be very helpful for allowing a whitelist of request origins.

if (this.method === 'OPTIONS') {
  this.status = 204;
  return;
}

There is no need to yield next if we have an OPTIONS request as we should process the response immediately.

Are you planning to support koa@2?

koa deprecated Support for generators will been removed in v3. See the documentation for examples of how to convert old middleware https://github.com/koajs/koa/tree/v2.x#old-signature-middleware-v1x

Could origin take an array of allowed origins?

if you run tests in #10 you will see that when setting origin to true the middleware stringifies a function into the header.
When setting origin to false there are still cors headers set.

I think these problems will pass away when you do some testing :)

yield next; statement should be at the end of the middleware as it is customary (which will allow me to place the middleware in the middleware stack according to my needs). Also the response for OPTIONS request should not yield anymore. So to fix both problems at once, we can simply modify the final 'if' statement like:

if (this.method === 'OPTIONS') {
  this.status = 204;
} else {
  yield next;
}

I think that CORS design is completely unnecessary, stupid, and so should be abandoned. I have laid down my arguments, if you think you know this issue pretty well, would you please look at it, and comment it.

https://github.com/jackzhp/CORS-should-retire
or
http://blog.sina.com.cn/s/blog_93b70ae70102wxe8.html

Hope you can contribute to the change!

Hi,

Is koa-cors supposed to work with koa-static? https://www.npmjs.com/package/koa-static

Is there any need to set cors headers on non options requests?

Access-Control-Allow-Methods from koa-router will not be visible.
Maybe there could be an option to handle this.
Or ignoring the header field if its already set.

If an error is thrown by someone in the app, ie. this.throw(400) the headers are reset here: https://github.com/koajs/koa/blob/master/lib/context.js#L118 and the cors header is lost.

Seems like this: https://github.com/evert0n/koa-cors/blob/master/index.js#L94
needs to be wrapped in a try catch and have the headers placed back in.

Hello,

I wanted to use koa-cors for my REST API but unfortunately had the problem that the cors headers are not set when an error is thrown (as there is no downstream anymore).

This leads to the problem that I get an xhr error in the browser when trying to authenticate over HTTP Basic as this is handled by koa-basic-auth as error.

Are there any reasons moving the yield next; to after the cors part?

Best,
Bo

methods: 'GET,HEAD,PUT,POST,DELETE,PATCH'

The option says origin expects a string, is it possible to allow an array of strings so you can allow more than one domain?

Can we fix somehow this?

http://stackoverflow.com/questions/5027705/error-in-chrome-content-type-is-not-allowed-by-access-control-allow-headers

Steps to reproduce:

• send post request on foreign domain
• set content-type header to application/json
• chrome makes options request
• chrome developer toolbar shows: Access-Control-Request-Headers:accept, x-requested-with, content-type
• but the server never gets the last one
• cors module responds with the same what it gets
• chrome expects to see content-type and throws "Content-Type is not allowed by Access-Control-Allow-Headers"

Accoding to https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#The_HTTP_response_headers:

If the server specifies an origin host rather than "*", then it must also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header.

Currently, the middleware does not set the Vary header.

In most cases it makes sense to just return a 204 on an OPTIONS request, but the specification says that a body can be included with the response. Could we have some sort of setting that makes the module not capture the OPTIONS request?

To clarify, I need a setting that does something like below:

if (options.captureOptions === true && this.method === 'OPTIONS') {
    this.status = 204;
} else {
    yield next;
}