I got it ：https://github.com/koajs/cors/blob/master/index.js#L138

Originally posted by @slip-box in #71 (comment)

allowHeaders don't proxy custom headers [1] to koa middleware. [2]

[1]

  server.applyMiddleware({
      app,
      cors: {
        allowHeaders: ['authorization'],
      },
    })

[2]

export const app = new Koa()
 app.use(async (ctx, next) => {
    ctx.req.headers.authorization // this is undefined
})

What is the reason it is not part of the default methods?

Koa 2 is released. 🎉

Hi,

I have a situation where when I receive a response with an error status (in this case status 416), there are no CORS headers present on the response. It works fine with otherwise. Any idea why this could be?

Cheers,

Nick

GMT koa deprecated Support for generators will be removed in v3. See the documentation for examples of how to convert old middleware https://github.com/koajs/koa/blob/master/docs/migration.md at server\index.js:6:5

app.use(cors())

Hi,
Loving the package so far! Well done.

The following code can be used to specify a specific origin for CORS using kcors:

var cors = require('kcors');

// Configure cross-origin requests from localhost:3000
var config = {origin: 'http://localhost:3000'};

app.use(cors(config));

It would be great if we could specify more than one origin via an array:

var config = {origin: ['http://localhost:3000', 'http://mydomain.com']};

app.use(cors(config));

It's possible to specify multiple hosts using separate Access-Control-Allow-Origin headers, e.g:

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Origin: http://mydomain.com

Can I submit a PR to add support for this?

Thanks!

In 677833d an unconditional yield next; has been added at the end of the middleware. It is breaking preflight requests on our servers because in earlier versions the middleware chain stopped at this.status = 204.

how do i set options

Describe the feature

At the moment the library does not allow handling the scenario in which the origin is not allowed to access the resource: it expects options. origin to always return a string. That leads to developers having to come up with a "workaround" configuration (for example here or here) which is not ideal:

• I'd rather not return any allowed domains to the caller if the caller is not allowed to call my API in the first place as it might undisclose details unnecessarily.
• Returning false/undefined from origin function causes the middleware to be completely ignored which seems to be a feature of this library as there's a unit test that proves this behaviour.
• Returning a null is not a good practice because of security issues as described in this issue.

If the request Origin is not allowed, the middleware should be able to respond to pre-flight requests immediately with no Access-Control headers being returned at all.

Checklist

• I have searched through GitHub issues for similar issues.
• I have completely read through the README and documentation.

original:
$ npm install @koa/cors@2 --save

new:

v2 latest:
$ npm install @koa/cors@2 --save

v3
$ npm install @koa/cors@3 --save

When using the default options, as the docs describe, without defining an origin, the response will set Access-Control-Allow-Origin to the request Origin header.

Enable cors with default options:
  origin: request Origin header

But if hit with a request that sets Origin: null, then the response will be Access-Control-Allow-Origin: null.

There's a lot of sources that say don't do this...
https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null

I'm not really an expert in this area, but would there be a better default behavior than..

// https://github.com/koajs/cors/blob/master/index.js#L66
origin = options.origin || requestOrigin;

... if the requestOrigin were null?

Please add a sentence to the documentation that it needs to be 'used' before the router, thanks!

see:
https://stackoverflow.com/questions/44775299/why-cant-koa-router-be-put-before-koa-cors

Please make this module spec-compliant :) An example where it is not that I noticed right away is that this module considers any request with an Origin request header to be a CORS request--this is actually not the indicator of what is or isn't a CORS request. You can find more within the spec.

The biggest failure right now is this module doesn't correctly handle pre flight requests, as it makes a mistakes in the processing of section 6.2 (http://www.w3.org/TR/cors/#resource-preflight-requests), step 3:

If there is no Access-Control-Request-Method header or if parsing failed, do not set any additional headers and terminate this set of steps. The request is outside the scope of this specification.

If I send an OPTIONS request with an Origin request header and no Access-Control-Request-Method request header, this module still adds CORS response headers.

You can find the spec here: http://www.w3.org/TR/cors/

Hi all: I need proxy some custom headers？what should i do ？thanks！

I don't understand why the latest commit sets the default Access-Control-Allow-Origin to *. This makes no difference to setting it as the request Origin, as both will break the browser's same-origin policy restrictions. The safest option is to default to empty, letting users specify the origin value themselves.

f31dac9

node throws this exception

error: uncaughtException: Cannot find module '@koa/cors' date=Mon Nov 20 2017 08:02:33

when requiring this module

const cors = require('@koa/cors');

Is this module still updated?

Grabbed from https://github.com/koajs/cors/blob/master/index.js#L59

Opened #44 for non async/await supported versions and #43 for a more up to date version.

#42 just fixes the test runner that was leaving connections hanging.

Can someone give a look on them please?

String|Function(ctx)} origin Access-Control-Allow-Origin, default is request Origin header
what is Function(ctx) expect return value?
I tried
origin:ctx=>ctx.request.origin
It doesn't work.

Describe the bug
While scanning my React.js application's manifest file using Vulert for vulnerability checks, I identified an issue associated with your package.

Reference
Upon conducting a vulnerability scan, the following references were identified:
Vulert Scan Report: Vulert Report
CVE Reference: CVE-2023-49803

I want to config Access-Control-Allow-Origin dynamically, while acquiring the configuration is an asynchronous operation.

Background

If a browser sends an OPTIONS request, but origin it not match, now koajs/cors will return 404 status code, due to https://github.com/koajs/cors/blob/master/index.js#L60

then the browser will warn 404, some user will confuse if they need to register an OPTION router.

Discuss

should it return 204 here?

I don't find any clear description at SPEC:

https://www.w3.org/TR/cors 7.1.5 Cross-Origin Request with Preflight

and according to spec below, OPTIONS should never return 404.

• https://tools.ietf.org/html/rfc7231#section-4.3.7 Responses to the OPTIONS method are not cacheable.
• https://tools.ietf.org/html/rfc7231#section-6.5.4 : A 404 response is cacheable by default;

and Express will return 204, https://github.com/expressjs/cors/blob/master/lib/index.js#L178

I am using koa/cors for a REST API I'm developing. I noticed that setting up a CDN didn't reduce the number of requests, so I started checking everything and eventually found that cors adds the Vary: Origin header, which was preventing the CDN from working.

I don't know a lot about http headers and CORS internal workings so I just solved it by adding ctx.remove('Vary') when setting Cache-Control header. Maybe I'm doing something wrong but with that everything seems to work fine. I'd appreciate any guidance.

Thanks

I think that CORS design is completely unnecessary, 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

Hi guys, any plans to support Access-Control-Request-Private-Network?

this my config

app.use(convert(require('koa-static')(__dirname + '/public')))
app.use(cors({
  origin: function (ctx) {
    return '*'; 
  },
  exposeHeaders: ['WWW-Authenticate', 'Server-Authorization'],
  maxAge: 5,
  credentials: true,
  allowMethods: ['GET', 'POST', 'DELETE'],
  allowHeaders: ['Content-Type', 'Authorization', 'Accept'],
}))

Error reporting when I access files under public
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I read the code and felt puzzle about setting the status 204 forever for the result of optionsrequest for Preflight Request. I thought it should be controlled by other components like a real backend( my one is django)

It would be greate if you can reply to give a hand. 👍

If origin is set to * it is not sent. It doesn't matter if it's left as the default or set explicitly.

When using ctx.throw or ctx.assert the cors headers are not sent back. Maybe I'm using it wrong but any help would be welcome :).

example:

router.post('/', (ctx) => {
  let {name, jurisdiction, parentTitle} = ctx.request.body;
  const project = ctx.request.body;

  ctx.assert(name && jurisdiction && parentTitle, 400);

Thanks!

The recent breaking change to fix this advisory fixes the scenario where an origin is not specified but it breaks the scenario where it is.

If an Origin is supplied in the request, the spec states the server "must return the origin for the specific client making the request" (i.e. the origin passed in). All my apps and test suites are configured to expect this behaviour, however this library now returns * instead.

Could you confirm that was the intended behaviour, to ignore the incoming request origin in all scenarios?

I use koa-socket-2.

'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Hi

I want this project doesn't require additional typing library(which is @types/koa__cors) when coding in TypeScript. This could be solved by adding .d.ts file. Any ideas?

does koa cors still maintains ? you guys need any help ? I am happy to collaborate

I tried

app.use(cors({
  origin: function (ctx) {
    if (['https://www.example1.com', 'https://www.example2.com'].includes(ctx.get('Origin'))) {
      return ctx.get('Origin');
    }
    return null;
  }
}));

But it doesn't work, any solution ?

This morning I ran npm outdated this morning and noticed something funny with kcors:

An older version has been published as @latest on npm:

The headers don't seem to be getting set on the latest version of Koa 2 with node 6.2. Any ideas?

in https://www.npmjs.com/package/@koa/cors , it README shows

{String|Function(ctx)} origin Access-Control-Allow-Origin, default is '*'

But in github, it README shows

- {String|Function(ctx)} origin Access-Control-Allow-Origin, default is request Origin header

github version is actual behavior

Specifically:

Can I do

const cors = require ('kcors');
var optCors = { 'some':'set','of':'options' }
var router = require('koa-router')({prefix: '/api'});
router.use( cors ( {optCors} ) );

or even

router.get('/someUrl', cors(), function* (next){
// some processing
})

instead of the standard documented app.use(cors())

might be better than kcors, especially since there's a koa-cors that is no longer maintained