feat(core): add asyncapi security-defined lint rule#2759
Conversation
🦋 Changeset detectedLatest commit: 959b639 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
harshit078
changed the title
harshit078
changed the title
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
vadyvas
left a comment
vadyvas
left a comment
There was a problem hiding this comment.
I would suggest a slightly different approach:
- keep the AsyncAPI logic separate and do not reuse shared logic from the OAS rule
- use the same rule name,
security-defined, for AsyncAPI as well, and register the AsyncAPI implementation in the AsyncAPI ruleset - do not update the v1 docs in this PR
I think this would make the change smaller, clearer, and safer.
Thank you for the contribution, overall the PR looks good
vadyvas
left a comment
vadyvas
left a comment
There was a problem hiding this comment.
left a few comments, could you take a look?
| 'info-contact': InfoContact as Async2Rule, | ||
| 'info-license-strict': InfoLicenseStrict as Async2Rule, | ||
| 'operation-operationId': OperationOperationId as Async2Rule, | ||
| 'security-defined': SecurityDefined, |
There was a problem hiding this comment.
Please add support for AsyncAPI 3 as well. Right now the rule only applies to AsyncAPI2
There was a problem hiding this comment.
The code uses the rule name security-defined, but the docs still say asyncapi-operation-security-defined
Can you update related changes?
| @@ -0,0 +1,83 @@ | |||
| # asyncapi-operation-security-defined | |||
There was a problem hiding this comment.
Please don’t add this rule to the v1 docs
|
Hi @AlbinaBlazhko17 , I have addressed all the refactoring you mentioned and fixed all comments by cursor. Can you check again ? Thanks for the patience to go back and forth ! |
| --- | ||
|
|
||
| Added `security-defined` rule for AsyncAPI 2.x and 3.x. | ||
| This rule reports when a security scheme referenced from an operation or server `security` array is not defined in `components.securitySchemes`. |
There was a problem hiding this comment.
Please, add warning here, because it is breaking change due to adding new rule in recommended ruleset with error severity.
e.g.
**Warning**: this change may break workflows that relied on root-level server inheritance.
And, i think, we need to remove second sentence, which explain how rule works.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit cc37359. Configure here.
|
Hi @AlbinaBlazhko17 , I have addressed all the last comments you left and Pr is good to review again. Thanks ! |
| type SecuredOperation = Async2Operation | Async3Operation; | ||
| type SecuredTrait = Async2OperationTrait | Async3OperationTrait; | ||
|
|
||
| export function isOperationSecured( |
There was a problem hiding this comment.
This function seems to work only with Async2 and Async3 but located in utils and have general naming.
If it is only work with Async, will it make sense to change its name to isAsyncOperationSecured ?
Also please consider file ranaming.
There was a problem hiding this comment.
Hi @DmitryAnansky , I renamed and shifted this function to utils for a shared logic as guided by -
tatomyr
changed the title
5 participants
What/Why/How?
asyncapi-operation-security-definedrule for AsyncAPI 2.x which reports when a security scheme referenced from an operation or serversecurityarray is not defined in ``components.securitySchemes.Reference
#2667
Testing
Screenshots (optional)
Check yourself
Security
Note
Medium Risk
New default
errorin recommended AsyncAPI rulesets can break existing CI for specs with loose security; the rule touches security semantics (refs, server applicability, traits) where edge-case behavior matters.Overview
Adds a built-in
security-definedlint rule for AsyncAPI 2.x and 3.0, mirroring the OpenAPI rule’s intent: catch bad or missing security configuration at lint time instead of at runtime.For AsyncAPI 2.x, the rule validates scheme names on operation/server
securityagainstcomponents.securitySchemes, and flags operations with no operation-level security when every applicable server also lacks security (with channel server bindings, traits, and component servers handled).For AsyncAPI 3.0, it validates
$refs undersecurity(must target#/components/securitySchemes/...and resolve), and applies the same “operation must be secured” checks on rootoperations(including$refintocomponents.operations), while skipping reusable definitions undercomponents.operations.The rule is registered in
async2/async3rule sets, included in minimal/recommended/all presets (errorin recommended;warnin minimal), and documented (new async rule page, guides, sidebars). Visitor typings andisOperationSecuredsupport trait-aware checks.Breaking note: with
recommended, AsyncAPI specs that previously passed may now fail on undefined security refs or unsecured operations.Minor unrelated changes: AsyncAPI split CLI code gets stricter
componentstyping; respect-core gains a test for Arazzo workflow context resolution without aworkflowspath segment.Reviewed by Cursor Bugbot for commit 959b639. Bugbot is set up for automated code reviews on this repo. Configure here.