Different behavior between function and string as origin
See original GitHub issueHi! This issue is a follow-up of https://github.com/socketio/socket.io/issues/3947.
With:
{
origin: 'http://origin.ok'
}
OPTIONS
requests are always ended with an HTTP 204 status here: https://github.com/expressjs/cors/blob/c49ca10e92ac07f98a3b06783d3e6ba0ea5b70c7/lib/index.js#L178-L180
With:
{
origin: function verifyOrigin(origin, callback) {
if (origin === 'http://origin.ok') {
callback(null, origin);
} else {
callback(new Error('Access not allowed from the specified origin: ' + origin));
}
}
}
If the check pass, the OPTIONS
request also ends with an HTTP 204 status. But if it doesn’t, it gets forwarded to the next handler: https://github.com/expressjs/cors/blob/c49ca10e92ac07f98a3b06783d3e6ba0ea5b70c7/lib/index.js#L220-L221
Which might be a bit surprising.
Would it make sense to add a case for OPTIONS
requests? Something like:
if (originCallback) {
originCallback(req.headers.origin, function (err2, origin) {
if (err2 || !origin) {
- next(err2);
+ if (req.method === 'OPTIONS' && !options.preflightContinue) {
+ res.statusCode = options.optionsSuccessStatus; // not an actual success, but you get the idea
+ res.setHeader('Content-Length', '0');
+ res.end();
+ } else {
+ next(err2);
+ }
} else {
corsOptions.origin = origin;
cors(corsOptions, req, res, next);
}
});
} else {
next();
}
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Help Online - LabTalk Programming - String - OriginLab
This function performs a case-sensitive comparison of the string with another string. Syntax. int nRet = str.Compare(str2$);.
Read more >Question related to std::string object and c_str() method in 3 ...
Can anyone explain the different behavior in three greet functions? What is the the scope of the object mentioned in each of the...
Read more >Comparison of programming languages (string functions)
String functions are used in computer programming languages to manipulate a string or query information about a string (some do both).
Read more >Useful string methods - Learn web development | MDN
Strings as objects ... your variable becomes a string object instance, and as a result has a large number of properties and methods...
Read more >Values that you specify when you create or update a distribution
Choose one of the following options: None (Improves Caching) Choose this option if your origin returns the same version of an object regardless...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry everyone, I went back over the docs and for the origin, false to disable CORS. The current behavior is correct in this case, as the preflight behavior is a condition of CORS being enabled. The correct callback response to have CORS enabled but reject the CORS request as denied is actually
callback(null, [])
. Apologies for the confusion as I am not the original author and took over tge module a while back. I relized my error here when I was just looking at tge original commits.Thanks for the quick feedback!
Nonetheless, since the check is
if (err2 || !origin)
, usingcallback(null, false)
will have the same result as passing an error, isn’t it?