feat: add apply-root-security decorator - #54
Conversation
| @@ -0,0 +1,12 @@ | |||
| import spreadSecurityToOperations from "./decorator"; | |||
There was a problem hiding this comment.
| import spreadSecurityToOperations from "./decorator"; | |
| import spreadSecurityToOperations from "./decorator.js"; |
There was a problem hiding this comment.
After all, it's better to define the decorator in place. No need to import it.
|
|
||
| ```bash | ||
| # Step 1: join the specs | ||
| redocly join foo.yaml bar.yaml -o joined.yaml |
There was a problem hiding this comment.
There's no point in joining them as it won't change anything. Unless there are other multiple docs with paths and operations that get joined.
| @@ -0,0 +1,15 @@ | |||
| export default function spreadSecurityToOperations({ pathSecurityFile } = {}) { | |||
| return { | |||
| Operation: { | |||
There was a problem hiding this comment.
This is too complicated. I'd simply apply the referenced file's root security to the bundled description's root. That should be enough.
| id: "security-plugin", | ||
| decorators: { | ||
| oas3: { | ||
| "spread-root-security": ({ pathSecurityFile }) => { |
There was a problem hiding this comment.
| "spread-root-security": ({ pathSecurityFile }) => { | |
| "apply-root-security": ({ pathSecurityFile }) => { |
It's not spread.
There was a problem hiding this comment.
Will this decorator apply securitySchemes to the bundled document too? Otherwise we'll get a wrong security defined.
There was a problem hiding this comment.
Good catch, It didn't. Fixed that
| const doc = resolvePath(pathSecurityFile, config); | ||
|
|
||
| if (doc?.security !== undefined || root.security === undefined){ | ||
| root.security = doc?.security; |
There was a problem hiding this comment.
What if the openapi already has security defined? Will this decorator override the existing one?
There was a problem hiding this comment.
BTW, let's apply some formatting.
There was a problem hiding this comment.
It shouldn't. That was a typo, condition here should be AND not OR, fixed that.
Also, fixed formatting.
| leave(root, { config }) { | ||
| const doc = resolvePath(pathSecurityFile, config); | ||
|
|
||
| if (doc?.security !== undefined && root.security === undefined){ |
There was a problem hiding this comment.
Maybe we can merge the doc and root security somehow? Does it make sense?
There was a problem hiding this comment.
Yeah, good point
|
|
||
| validateOpenapiSpecification(pathSecurityFile, doc, specVersion); | ||
|
|
||
| if (specVersion === 'oas2') { |
There was a problem hiding this comment.
Let's not overcomplicate it. The purpose of the Cookbook is to demonstrate the possibility, not provide the ultimate solution. Let's focus on OAS3 first.
|
|
||
| function mergeSecurityRequirements(root, doc) { | ||
| if (!Array.isArray(doc?.security)) return; | ||
| root.security = [...(root.security || []), ...doc.security]; |
There was a problem hiding this comment.
If there's already such a security requirement, will it duplicate it?
There was a problem hiding this comment.
Good catch, It will duplicate. Added a check for that
| root.security = [...(root.security || []), ...doc.security]; | ||
| }; | ||
|
|
||
| function mergeSecuritySchemes(root, doc) { |
There was a problem hiding this comment.
Could you use names like source and targed?
There was a problem hiding this comment.
Yes, I can. Renamed
| @@ -0,0 +1,11 @@ | |||
| import applyRootSecurity from "./decorator.js"; | |||
There was a problem hiding this comment.
| import applyRootSecurity from "./decorator.js"; | |
| import { applyRootSecurity } from "./decorator.js"; |
| @@ -0,0 +1,54 @@ | |||
| const applyRootSecurity = ({ pathSecurityFile } = {}) => { | |||
There was a problem hiding this comment.
| const applyRootSecurity = ({ pathSecurityFile } = {}) => { | |
| export const applyRootSecurity = ({ pathSecurityFile } = {}) => { |
Adds a custom decorator that apply root-level security from one spec defined in another after using
redocly bundle.Reference: #1409