feat(core): add asyncapi-operation-security-defined lint rule#2759
feat(core): add asyncapi-operation-security-defined lint rule#2759harshit078 wants to merge 30 commits into
Conversation
🦋 Changeset detectedLatest commit: 97dbad9 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 |
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
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
| return { | ||
| ref: { | ||
| leave(node, { location, report }, resolved) { | ||
| if (!SECURITY_LOCATION.test(location.pointer)) return; |
There was a problem hiding this comment.
Please, avoid using regex pattern to check the location. For the rules we have visitors pattern, so you can use SecurityScheme visitor here.
There was a problem hiding this comment.
sure thanks for the help. I'll push a fix for it
| info-contact: off | ||
| info-license-strict: warn | ||
| operation-operationId: warn | ||
| asyncapi-operation-security-defined: error |
There was a problem hiding this comment.
It looks like you forgot to remove the new rule from the v1 docs. Please, remove this line
| return { | ||
| ref: { | ||
| leave(node, { type, location, report }, resolved) { | ||
| if (type.name !== 'SecurityScheme') return; |
There was a problem hiding this comment.
Please, follow our visitors pattern as you did in rule for async2
| if (scheme.defined) continue; | ||
| for (const reportedFromLocation of scheme.from) { | ||
| report({ | ||
| message: `There is no \`${name}\` security scheme defined.`, |
There was a problem hiding this comment.
I think we should align these rules with the existing OpenAPI; in other words, we need to report if any operation doesn't have a security defined
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 1c4f368. Configure here.
| if (!isRef(item)) continue; | ||
| const itemLocation = location.child([i]); | ||
| const ref = item.$ref; | ||
| if (!ref.startsWith(COMPONENT_SCHEME_PREFIX)) { |
There was a problem hiding this comment.
Please, avoid using this type of check, because it will cause issues in future. e.g. other.yaml#/components/securitySchemes/jwt will be rejected. Try to track defined schemes by their location.absolutePointer and in SecuritySchemeList resolve each ref and compare absolute pointers.
| "@redocly/openapi-core": minor | ||
| --- | ||
|
|
||
| Added `security-defined` rule for AsyncAPI 2.x that 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 in changeset AsyncAPI 3.x support.
|
Thanks @harshit078 for your patience. Almost there. My biggest concern is based on AsyncAPI v3 rule and manually checking ref locations, i left comment regarding it. |

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
Adds a new built-in AsyncAPI lint rule and enables it in default rulesets (
recommended/all), which can introduce new lint failures for existing AsyncAPI specs.Overview
Adds a new AsyncAPI built-in rule,
security-defined, that reports (1) operation/serversecurityreferences that don’t exist incomponents.securitySchemesand (2) operations missingsecurityentirely; AsyncAPI 3.0 additionally validates that security$refs point into#/components/securitySchemes.Enables the rule across core ruleset presets (
all,recommended,recommended-strict,minimal,spec), updates config/type plumbing and snapshots, and adds dedicated AsyncAPI 2.x/3.0 test coverage plus new documentation pages and sidebar/ruleset-template entries.Reviewed by Cursor Bugbot for commit 97dbad9. Bugbot is set up for automated code reviews on this repo. Configure here.