-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISSUE: 501. CORS Support. #3032
Changes from 4 commits
4ce0a0e
1ad7db3
88eeebb
b9a8b2f
e3a6471
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,3 @@ | ||
- Add: CORS Preflight Requests support for /v2 and /v2/entities, -corsMaxAge switch (#501) | ||
- Add: CORS Preflight Requests support for all NGSIv2 resources, -corsMaxAge switch (#501) | ||
- Fix: case-sensitive header duplication (e.g. "Content-Type" and "Content-type") in custom notifications (#2893) | ||
- Fix: bug in GTE and LTE operations in query filters (q/mq), both for GET operations and subscriptions (#2995) |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,6 +33,7 @@ | |
|
||
#include "ngsi/ParseData.h" | ||
#include "rest/ConnectionInfo.h" | ||
#include "rest/rest.h" | ||
#include "rest/restReply.h" | ||
#include "rest/OrionError.h" | ||
#include "serviceRoutinesV2/badVerbGetDeletePatchOnly.h" | ||
|
@@ -55,11 +56,16 @@ std::string badVerbAllNotDelete | |
OrionError oe(SccBadVerb, ERROR_DESC_BAD_VERB); | ||
|
||
ciP->httpHeader.push_back("Allow"); | ||
ciP->httpHeaderValue.push_back("GET, PATCH, POST, PUT"); | ||
std::string headerValue = "GET, PATCH, POST, PUT"; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just for curiosity, is there any 'established' order for the verbs/methods ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting question... what does the CORS specification say about that? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. CORS specification does not provide any rules for the order of the methods and the example scenarios provided do not seem to be following any pattern. Please see the example scneario at the end of the subsection: 7.1.5 Cross-Origin Request with Preflight. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, NTC (alphabetic order seems ok to me) I think I used an (by myself invented) "estimated use-frequency order", as: GOT. POST, PUT. PATCH ... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Taking into account order doesn't matter from specification point of view, I don't see any value on changing that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Uniformity seems like reason enough to me (surprised to hear that you don't care :-)) |
||
//OPTIONS verb is only available for V2 API | ||
if ((corsEnabled == true) && (ciP->apiVersion == V2)) | ||
{ | ||
headerValue = headerValue + ", OPTIONS"; | ||
} | ||
ciP->httpHeaderValue.push_back(headerValue); | ||
ciP->httpStatusCode = SccBadVerb; | ||
|
||
alarmMgr.badInput(clientIp, details); | ||
|
||
return (ciP->apiVersion == V1 || ciP->apiVersion == NO_VERSION)? "" : oe.smartRender(ciP->apiVersion); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A cryptic way of checking if the char string is empty but it's ok... :)
Just to be sure... how
restAllowedOrigin
array is initialized? Can we asure that first element is zero? Or it is random and could be initilizalied with random stuff?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it was suggested by @kzangeli :) I think it is better than checking the length.
restAllowedOrigin
gets the value of -corsOrigin switch or if the switch is not used, initialized with empty string,""
. For empty string, the first char will always be zero.By the way, since we are talking about the variable, we have re-used some of the code Jose Manuel wrote for the first CORS implementation and some of the variable names that made sense back then, now got a bit confusing. Especially restAllowedOrigin. So this is the flow we have now:
-corsOrigin
switch value and assign it toallowedOrigin
incontextBroker.cpp
allowedOrigin
variable incontextBroker.cpp
rest.cpp
calledrestAllowedOrigin
restInit
function, the passed value is mapped to_allowedOrigin
in the signature and the value is re-assigned torestAllowedOrigin
.As you see, there are a lot of name changes which makes the code hard to read and harder to maintain. I propose using the same name corsOrigin except the method signature of
restInit
where we can have it as_corsOrigin
. Same goes for restCORSMaxAge.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the piece of the puzzle I missed. I didn't know if the argument parsing library puts
""
in the case of missing swich or just left the holding variable with undefined content. I understand is the former.Sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is related with
That
_i ""
ensures that in the case of not using-corsOrigin
at the CLI, the value for allowedOrigin is univocally set to empty string, isn't it @kzangeli ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. So this comment (and with it the whole PR, as far as I remember) is only pending of a new commit with the refactor in the variable names, as @McMutton suggested above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in e3a6471