[REQ] [cpp-qt-client] Option to disable OAuth generation

[limentas]

Is your feature request related to a problem? Please describe.

At this moment it is impossible to disable OAuth flow generation. And that's great that OAuth is implemented. But it has some issues:

1. It requires Qt GUI module as per [REQ] Disable generated "oauth" function for cpp-qt-client to remove "QtGui" dependency #16082 request.
2. It doesn't handle errors from OAuth auth requests and this leads to a crash.
3. Every generated API class has own OauthCredentials object which stores tokens and these objects don't share information between different APIs. This leads to extra auth requests.
4. It is impossible to specify your own client id, client secret for client credentials grant type.

Maybe something else. These are the issues I have faced. In my case it would be easier to do authentication manually once and then reuse the token over multiple calls to different APIs. I have to say that some of the issues is easy to fix but some of them requires refactoring (for example sharing credentials).

Describe the solution you'd like

I would like to have a config option to disable generating OAuth code and the main point for me to disable this automatic flow when any HTTP 401 goes via OAuth flow at first and never reaches user code.

Describe alternatives you've considered

• Fixing all the issues looks too complicated to me
• Another option would be to generate an API class method that disables OAuth flow and should be called in advance. This is also possible but this will not remove dependency on Qt Gui.

Additional context

Here I would like to gather opinions and objections about such a feature. I will take care about implementation afterwards.

[wing328]

sounds good to me

what about using {{#hasOAuthMethods}} ... {{/hasOAuthMethods}} in the template?

openapi-generator/modules/openapi-generator/src/main/resources/go/go.sum.mustache

Line 7 in a53ebb3

{{#hasOAuthMethods}}

[limentas]

I think some of the problems could already be resolved by editing OpenAPI spec:
https://github.com/OpenAPITools/openapi-generator/blame/master/modules/openapi-generator/src/main/resources/cpp-qt-client/api-body.mustache#L699
But the problem is that we don't always have a control on OpenAPI spec. I'm generating a client code and spec is something I get from independent sources. In theory it is possible to have local changes to the spec, but it is not very maintainable solution. Similar to manually editing a generated code.

[wing328]

if the spec already contains oauth authentication in some endpoints (which also support other authentication scheme such as API key), then I think one potential solution is to add a new rule in openapi normalizer to keep authentication scheme based on names

[limentas]

Yes, I think this could also work. And I see that would be more universal solution that can be used for other generators. I could also implement this. Let me know which option is better.

[wing328]

please go with the normalizer option

you can find reference PRs on how we add new rules to normalizer: https://github.com/OpenAPITools/openapi-generator/pulls?q=is%3Apr+is%3Amerged+label%3A%22OpenAPI+Normalizer%22

[limentas]

I started implementing this functionality (https://github.com/limentas/openapi-generator/tree/security-schemes-filter) and have something to discuss. At first I have tried to manually remove oauth security schemes and it works for me with C++ qt client generator. But what concerns me is the fact that these security schemes are referenced in operations (https://swagger.io/specification/#operation-object). I could also remove these references but I don't think that standard approach with x-internal will work there.
Any thoughts?
@wing328

[wing328]

then I think one potential solution is to add a new rule in openapi normalizer to keep authentication scheme based on names

did your approach get a list of authentication scheme based on names in the normalizer and keep these in the spec (e.g. operations) or the other way around?

[limentas]

I have made it similar to FILTER option: one can pick only those security schemes that satisfies filtering options by key/type.

[wing328]

can you please create a draft PR with what you've so far and we will take a further look?

[limentas]

Opened draft PR:
#23174