Generated Openapi / Swagger does not contain Authorization definitions

[Syndlex]

Summary

We used your generated Openapi documentation to generate our own client.

The Problem here is that you Openapi spec does not contain the Authorization definitions. For securitySchemes and api_key headers.

Steps to Reproduce

1. Download your Open api Spec from https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.23/api/api.swagger.json
2. Load the spec into https://editor.swagger.io/
3. generate client with editor
4. clients are unable to mount authorization components

Current Result

the client is not able to call your api with the authorization.
Since the generated code is restricted it is not possible to go around this bug on a call by call basis.

Expected Result

possibility to use the authorization on every backendcall

Deployment

The Things Stack Community Edition

Proposed Fix

Change the generator to include the autorizations

This is describte within this issue grpc-ecosystem/grpc-gateway#309

https://github.com/grpc-ecosystem/grpc-gateway/blob/main/examples/internal/proto/examplepb/a_bit_of_everything.proto#L612
According to this example every RPC definition that needs a Authorization has to have a option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_operation)

I don't know grpc well enough here. Is it Possible to write this definition somewhere and reuse this Option?
It would still be a lot of manual Labor but a possible Solution to add the authorization definition to every endpoint that needs it.

Contributing

• I can help by doing more research.
• I can help by implementing a fix after the proposal above is approved.
• I can help by testing the fix before it's released.

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[johanstokking]

Thanks @Syndlex for filing and for the pointer to declaring this.

We are currently working on a big refactor to get rid of gogoproto and use vanilla protobuf instead. The GRPC gateway is definitely part of this overhaul. We may be able to add these options easily, but as lots of things are moving on the proto side, I rather wait until we got rid of gogoproto. References #2798.

Just for my information; what client are you generating? Does this really stop you from using a client?

[Syndlex]

We are generating a Java client with the Apache-Http Libary as a Setting.
But the problem we are facing will include every possible client.

For people searching for a solution with self generated code:
It is possible to use the generated code by giving one API Key to the apache-Http-Client itself as a default header for all communication.

The Problem is that we build a multi-tanant system. Every call will have different API-key.
Without the mapping in the openapi-spec it is not possible to pass a key to the generated api.
We currently just use half of the generated API and build the API Keys into our definitions.

Using the default header Method would be a security nightmare.
I think your openapi and grpc approach is a create possibility for a ploygloth-api. :)

There are a lot of API Calls within the spec that are not documented on your homepage. At least I could not find them there. :)

Thanks for the Information @johanstokking

[johanstokking]

I see. Yeah I suppose most generated clients will allow you to pass custom headers. I hope this is not blocking users, but I understand the annoyance.

Blocked on #2798