evert0n / koa-cors Goto Github PK
View Code? Open in Web Editor NEWCORS middleware for Koa
License: MIT License
CORS middleware for Koa
License: MIT License
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
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;
}
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.
Hi,
Is koa-cors supposed to work with koa-static? https://www.npmjs.com/package/koa-static
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;
}
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.
ctx.throw(...)
does not seem to send the access control headers
The option says origin
expects a string, is it possible to allow an array of strings so you can allow more than one domain?
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.
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
Can we fix somehow this?
Steps to reproduce:
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.
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.
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 :)
Is there any need to set cors headers on non options requests?
What am I doing wrong?
I get a JSON parse error:
app
.use(bodyParser())
.use(cors({
methods: ['GET', 'PUT', 'POST', 'PATCH', 'DELETE']
}))
methods: 'GET,HEAD,PUT,POST,DELETE,PATCH'
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!
Could origin
take an array of allowed 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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.