-
Notifications
You must be signed in to change notification settings - Fork 43
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
Scopes enum is required even for Bearer authentication #65
Comments
Yes, that restriction is quite bothersome and should be relaxed. I unfortunately haven't gotten around to it. |
I haven't really thought this through very thoroughly, but would an easy improvement be to change the type parameter in AuthProvider.Security, SecurityShemeModel to just require a Described, and not an Enum? For example:
Or are you using the fact that it's an Enum for something somewhere? If not, that seems something that could be left to the discretion of whoever is using the library. In my head it wouldn't be a breaking change for any current users (though again, I might easily be missing something). And in my case it would allow me to say |
Enum is used for the ".name" and serialization, but besides that it was only meant as type enforcement. I think the issue with removing the Enum would be that the security model would be improperly generated. Replacing it with a String is possible, but generally using language types directly is unadvisable. Maybe a wrapper that handles the serialization properly ? |
As far as I understand the OpenAPI documentation, Scopes should be an empty list when using Bearer authentication. See: https://swagger.io/docs/specification/authentication/bearer-authentication/
In Ktor-OpenAPI-Generator, due to the way com.papsign.ktor.openapigen.modules.providers.AuthProvider.Security is defined, it seems that we must still have an Enum class with scopes even when only supporting Bearer authentication: requierments must be a List, "where T: Enum" and T is a Described.
Intuitively, I think a bearer scheme should be possible to define either as follows, skipping the requirements parameter:
Or as follows, providing an empty list:
But both of these result in compilation errors.
The solution for now has been to have "dummy enum" that's a subtype of Described, as follows:
...and then using that to define an empty list that can be sent to the Security class:
But the "dummy enum" feels out of place, and is never used anywhere apart from placating the type system. Unless I'm missing something?
The text was updated successfully, but these errors were encountered: