BUG: output format JSON generates invalid security scope for empty array

[WizMe-M]

Reproduce

Minimal repro structure

1. Create foo.proto:

syntax = "proto3";
package foo;

option go_package = 'example.com/example/foo';

service FooService {
    rpc FooBar(FooRequest) returns (FooResponse);
  }

message FooRequest {
}

message FooResponse {
}

2. Add api_openapi.yaml:

openapi:
  document:
    components:
      security_schemes:
        MyJwtBearer:
          type: http
          name: Authorization
          in: header
          scheme: bearer
          bearer_format: JWT

  services:
    - selector: 'foo.FooService'
      methods:
        FooBar:
          security:
            - name: MyJwtBearer
              scopes: [ ] # core setting

gateway:
  endpoints:
    - selector: 'foo.FooService.FooBar'
      post: '/foo'
      body: '*'

3. Add buf.gen.yaml:

version: v2

plugins: 
  - local: ../protoc-gen-openapiv3 # or remote to buf.build
    out: ../gen
    opt:
      - openapi_config=api_openapi.yaml
      - gateway_config=api_openapi.yaml
      - output_format=json # core setting

4. Run buf generate
5. Change output_format to json
6. Run buf generate again

Actual behavior

Generated files

YAML

paths:
  /foo:
    post:
      ...
      security:
        - MyJwtBearer: []

JSON

  "paths": {
    "/foo": {
      "post": {
        ....
        "security": [
          {
            "MyJwtBearer": null
          }
        ]
      }

If we take a look into gemerated apidocs we will see that:

• yaml-specification has valid scope ([]) for MyJwtBearer in /foo endpoint
• json-specification has null scope for MyJwtBearer in /foo endpoint

If we check them out in Swagger Editor we will see, that json spec (with null scope) is invalid and editor misses auth for the endpoint.

Broken auth img

Expected behavior

Both yaml and json specs (output formats) will have the same identical scope value (empty array [])

[peymanmortazavi]

@WizMe-M nice find, yeah we should definitely resolve this. I'll take a look this weekend, I imagine we'd have to use custom types and encode differently based on the value but it's been a while so I might be off here.