added securityScheme #226
added securityScheme #226
Conversation
Yeah I'll work on it but this is a busy week and it might require a couple of days since I would like to add the possibility to combine multiple requirements: (requirement1 OR requirement2) AND requirement3 It might make sense to add the scope of a requirement as well https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#security-requirement-object I will also add some test to cover the feature! |
There was a problem hiding this comment.
We will 100% need a docs update for this (it doesn't have to exist in this PR if you don't have the time. I thank you for the contribution enough).
That being said, and looking at this pretty late. This looks fantastic. To play devils advocate. What are the thoughts on making the OR logic be a new OptionSecurity entry on the route. That might possibly simplify the interface/make it more clear.
Again I didn't look closely and won't have the time til Friday. But that's my initial feedback. I'll more closely friday unless another team member beats me to it.
|
Was able to get to this today. Disregard my comment as I like this. I realized OR logic with separate calls to Final thoughts:
|
On point 2, yes of course I will work on it! How strict do you think the validation rules should be? |
Co-authored-by: ccoVeille <3875889+ccoVeille@users.noreply.github.com>
|
Oh sorry for not being clear. I just meant “ensure the security schema being asked on the route exists in the security schemas on the server.” Just check the map if not panic so we can tell the user early. 😅 sorry saying validate something in terms of OpenAPI can be super ambiguous. |
ahahah perfect, do you think that something like this could be enough? // Validate input is not empty
if len(securityRequirements) == 0 {
panic("at least one security requirement must be provided")
}
// Validate the security scheme exists in components
for _, req := range securityRequirements {
for schemeName := range req {
if r.OpenAPI != nil && r.OpenAPI.Components != nil {
if _, exists := r.OpenAPI.Components.SecuritySchemes[schemeName]; !exists {
panic(fmt.Sprintf("security scheme '%s' not defined in components", schemeName))
}
}
}
} |
|
Yes, you can remove the nil checks as well as everything is new'd up when the server is created. One thing that is interesting. If we moved away from the varadic input to just a single input we wouldn't need the extra for loop |
| @@ -76,6 +76,38 @@ var Summary = fuego.OptionSummary | |||
| // Description adds a description to the route. | |||
| var Description = fuego.OptionDescription | |||
|
|
|||
| // OptionSecurity configures security requirements to the route. | |||
There was a problem hiding this comment.
| // OptionSecurity configures security requirements to the route. | |
| // Security configures security requirements to the route. |
You renamed it
There was a problem hiding this comment.
Please update this. And this should be good to go. 😄
| // OptionSecurity(openapi3.SecurityRequirement{ | ||
| // "basic": [], // Requires basic auth | ||
| // "oauth2": ["read"] // AND requires oauth with read scope | ||
| // }) | ||
| // | ||
| // Multiple Schemes (OR Logic): | ||
| // | ||
| // Add multiple security requirements. | ||
| // At least one requirement must be satisfied: | ||
| // OptionSecurity( | ||
| // openapi3.SecurityRequirement{"basic": []}, // First option | ||
| // openapi3.SecurityRequirement{"oauth2": ["read"]} // Alternative option | ||
| // }) | ||
| // | ||
| // Mixing Approaches: | ||
| // | ||
| // Combine AND logic within requirements and OR logic between requirements: | ||
| // OptionSecurity( | ||
| // openapi3.SecurityRequirement{ | ||
| // "basic": [], // Requires basic auth | ||
| // "oauth2": ["read:user"] // AND oauth with read:user scope | ||
| // }, | ||
| // openapi3.SecurityRequirement{"apiKey": []} // OR alternative with API key | ||
| // }) |
There was a problem hiding this comment.
Same
| // OptionSecurity(openapi3.SecurityRequirement{ | |
| // "basic": [], // Requires basic auth | |
| // "oauth2": ["read"] // AND requires oauth with read scope | |
| // }) | |
| // | |
| // Multiple Schemes (OR Logic): | |
| // | |
| // Add multiple security requirements. | |
| // At least one requirement must be satisfied: | |
| // OptionSecurity( | |
| // openapi3.SecurityRequirement{"basic": []}, // First option | |
| // openapi3.SecurityRequirement{"oauth2": ["read"]} // Alternative option | |
| // }) | |
| // | |
| // Mixing Approaches: | |
| // | |
| // Combine AND logic within requirements and OR logic between requirements: | |
| // OptionSecurity( | |
| // openapi3.SecurityRequirement{ | |
| // "basic": [], // Requires basic auth | |
| // "oauth2": ["read:user"] // AND oauth with read:user scope | |
| // }, | |
| // openapi3.SecurityRequirement{"apiKey": []} // OR alternative with API key | |
| // }) | |
| // Security(openapi3.SecurityRequirement{ | |
| // "basic": [], // Requires basic auth | |
| // "oauth2": ["read"] // AND requires oauth with read scope | |
| // }) | |
| // | |
| // Multiple Schemes (OR Logic): | |
| // | |
| // Add multiple security requirements. | |
| // At least one requirement must be satisfied: | |
| // Security( | |
| // openapi3.SecurityRequirement{"basic": []}, // First option | |
| // openapi3.SecurityRequirement{"oauth2": ["read"]} // Alternative option | |
| // }) | |
| // | |
| // Mixing Approaches: | |
| // | |
| // Combine AND logic within requirements and OR logic between requirements: | |
| // Security( | |
| // openapi3.SecurityRequirement{ | |
| // "basic": [], // Requires basic auth | |
| // "oauth2": ["read:user"] // AND oauth with read:user scope | |
| // }, | |
| // openapi3.SecurityRequirement{"apiKey": []} // OR alternative with API key | |
| // }) |
| @@ -252,3 +253,27 @@ func OptionHide() func(*BaseRoute) { | |||
| r.Hidden = true | |||
| } | |||
| } | |||
|
|
|||
| func OptionSecurity(securityRequirements ...openapi3.SecurityRequirement) func(*BaseRoute) { | |||
There was a problem hiding this comment.
Maybe the comment could be added here
There was a problem hiding this comment.
I'm a fan of @ccoVeille requested changes. Once updated I'll approve
|
I've made the asked modifications myself on Thank you a lot @simonemastella for this feature, and @dylanhitt & @ccoVeille for proofreading this! 🙏🏼 |
Add WithSecurity Server Option and Route Security Documentation
Issue #221
Description
Adds a new
WithSecurityserver option to configure security schemes in the OpenAPI specification and documents the route-level.Security()method. This change improves the API by providing a complete security configuration solution at both the server and route levels.Features
Server-Level Security Configuration
WithSecurityfunction that accepts a map of security schemesRoute-Level Security
.Security(requirementName string)methodExample Usage
Server Security Configuration
Route Security Configuration
Benefits
Breaking Changes
None. This is a new feature that maintains backward compatibility.
Example