-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
feat: add security field at the operation level #505
feat: add security field at the operation level #505
Conversation
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.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
API.md
Outdated
@@ -265,6 +265,7 @@ | |||
* [.hasTraits()](#module_@asyncapi/parser+Operation+hasTraits) ⇒ <code>boolean</code> | |||
* [.messages()](#module_@asyncapi/parser+Operation+messages) ⇒ <code>Array.<Message></code> | |||
* [.message()](#module_@asyncapi/parser+Operation+message) ⇒ <code>Message</code> | |||
* [.OperationSecurityRequirement](#module_@asyncapi/parser+OperationSecurityRequirement) ⇐ <code>Base</code> |
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.
🤔 where is this defined?
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.
This doc should be generated automatically iirc.
Indeed OperationSecurityRequirement
is not the method you declared, but Security
.
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.
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.
Would you mind trying npm run docs
? This command should build the right API doc.
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.
The whole PR is ok, just delete the above and I can accept :)
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.
@smoya @magicmatatjahu I deleted my changes to the API doc and regenerated it using the above command.
Thanks for the PR @LokeshRishi! would you mind fixing the title to be compliant with Conventional Commits? You have an error on it. See https://github.com/asyncapi/parser-js/runs/5698773473?check_suite_focus=true
|
describe('#security()', function() { | ||
it('should return an array of security requirements objects', function() { | ||
const d = new Operation(js); | ||
expect(Array.isArray(d.security())).to.equal(true); |
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.
We need to test that the array is not empty. Otherwise, in the case it is empty, the logic inside the following forEach
won't ever be executed.
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.
@smoya Thanks for the review! I have incorporated the suggestion.
test/models/operation_test.js
Outdated
it('should return an array of security requirements objects', function() { | ||
const d = new Operation(js); | ||
expect(Array.isArray(d.security())).to.equal(true); | ||
expect(d.security().length > 0).to.equal(true); |
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.
Nitpick: I think you can simplify this with the proper Jest function:
expect(d.security().length > 0).to.equal(true); | |
expect(d.security()).toHaveLength(1); |
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.
.toHaveLength(1);
was throwing an error, I have update it to .to.have.lengthOf(1)
Kudos, SonarCloud Quality Gate passed! |
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.
LGTM!
@magicmatatjahu would you mind aproving workflows? Thanks! |
/rtm |
🎉 This PR is included in version 1.15.0-2022-04-release.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
We are using AsyncAPI specifications for publishing the subscriber specific details of our topics and associated payloads for our HTTP push use cases.
Our subscribable channels(or topics) are protected by a set of OAuth scopes (authorization code or client credentials) - that a potential subscriber needs to be aware of.
Here is a sample contract.
We are able to accommodate almost every detail of interest to an integrator/subscriber (THANK YOU) - with the exception of being able to call out the oauth scopes necessary for the subscription to the topic - i.e. the security aspect at the channel or rather channel/operation level.
The current specification is perhaps more aligned with a broker based topology - but ours is a pure push use case (to registered webhooks) and we need an ability to call out any security aspects at the channel operation level.
Related issue(s)
#434
asyncapi/spec-json-schemas#189