No difference between no security requirement and empty security requirement on Operations #1426

VisualBean · 2023-10-11T09:56:56Z

Describe the bug
There is no way of telling 'empty' from 'not defined' security requirement objects, during deserialization.
I.e no way of distinguishing the 2 different security requirement objects

paths:
  /pets:
    post:
      responses:
        '201':
          description: Created
      security: []
    get:
      responses:
        '200':
          description: A paged array of pets

Why is this important?

The specification states the following for Operation Security

To remove a top-level security declaration, an empty array can be used.

i.e security: []

however it is expected that if security is not defined on an operation level

get:
  responses:
    '200':
      description: A paged array of pets

That the global security is applied, defined on the top level document object.

in the following spec

openapi: '3.0.0'
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
security:
  - Authorization:
    - readwrite
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    post:
      responses:
        '201':
          description: Created
      security: []
    get:
      responses:
        '200':
          description: A paged array of pets
components:
  securitySchemes:
    Authorization:
      type: http
      scheme: bearer
      bearerFormat: JWT

post deserialization, it is impossible to determine which security is actually applied between the 2 operations, as both security requirements are deserialized into the same value
public IList<OpenApiSecurityRequirement> Security { get; set; } = new List<OpenApiSecurityRequirement>();
which ends up being empty in both cases.

The reason for this is most likely that during reading a new OpenApiSecurityRequirement() and as this is a dictionary, there is no way of specifying a null key, so to speak.

The problem being that the semantics between the 2 operations are different in the spec.

To Reproduce
Deserialize the above spec.

Expected behavior
To have a way of differentiating the 2 scenarios. (feasibly one would be empty, the other would be null.

Screenshots/Code Snippets

var input = @"openapi: '3.0.0'
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
security:
  - Authorization:
    - readwrite
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    post:
      responses:
        '201':
          description: Created
      security: []
    get:
      responses:
        '200':
          description: A paged array of pets
components:
  securitySchemes:
    Authorization:
      type: http
      scheme: bearer
      bearerFormat: JWT";
var document = new OpenApiStringReader().Read(input, out var diagnostics);

The text was updated successfully, but these errors were encountered:

darrelmiller · 2023-10-17T13:54:58Z

Thank you for bringing this to our attention. We have two options here to solve this problem. We can either add a new AnonymousAccess property to the OpenApiOperation object to allow users to explicitly state they want to override the security with no security. Or the other option is to stop defaulting the Security property to an empty list and treat a non-null value as an indication that they want to override the security.

// Option 1 - Breaking change
var operation = new OpenApiOperation();
operation.Security = null;  // Default value

// Set Anonymous access
operation.Security = new List<OpenApiSecurityRequirement>() [];  


// Option 2 - Non breaking change
var operation = new OpenApiOperation();
operation.Security = new List<OpenApiSecurityRequirement>() [];  // Default value
operation.AnonymousAccess = false;  // Anonymous access default

// Set Anonymous access
operation.AnonymousAccess = true;

We can do Option 2 in the current major version of OpenAPI.NET because it is not breaking, however, if we go with Option 1 we will need to wait until the v2 release.

VisualBean · 2023-10-17T14:57:15Z

Personally, I think nulling it, is more in line with what is expected from a dotnet point of view.

We specifically found empty vs we found nothing. so to speak.

Edited: to state the desired option without option number.

Option 1 does have the added effect of it, then being the ONLY list, that isn't newed up automatically.
also it 'might' technically be a breaking change for everyone relying on the existing behaviour.
So waiting for v2 might be the safest bet, in any case.

crudbee · 2023-10-18T07:17:33Z

I think option 1 and 2 have been flipped around, from the description to the examples: Option 1 adding AnonymousAccess, Option 2 defaulting to null.

Defaulting to null is the breaking change, so you both seem in agreement to wait for a v2 with it.

Null vs. default is similar to how it would be treated in F# (to my understanding) with option, where Some [] is the explicit override, and None is the lack of the property. The None tends to be mapped from null. I'd feel more comfortable with this option 2, explicit null, rather than a new property whose name I can't see mapping to the OpenAPI spec itself.

corentinvds · 2024-10-17T06:32:46Z

Hello,

Any update on this issue ?
Is there a known workaround other than not using global security specifications ?

Thanks

paulmendix · 2025-02-05T14:36:17Z

Hi! Has a decision been reached on how to best proceed? Returning null when no security property is set on the operation?

There seems to be a v2 version on it's way as preview5 has been released recently. I might be interested in contributing a fix (since I need a fix 😬) but then it's good to be sure what the approach should be.

darrelmiller · 2025-03-12T16:55:19Z

@paulmendix We would be most appreciative of a PR. However, this work should be only done after we have completed the NRT work #1971 and #2146

paulmendix · 2025-04-06T19:08:29Z

Thanks for the update! I will keep an eye on these issues

MaggieKimani1 · 2025-04-11T09:05:16Z

@paulmendix both the NRT and perf work are complete if you'd still like to contribute by sending a PR our way.🙂

paulmendix · 2025-04-11T12:54:57Z

Thanks @MaggieKimani1 I will give it a go

…rosoft#1426 make distinction between empty security requirements and no security requirements on an operation. empty security requirements are read as an empty list, no security requirements are read as null for OpenAPI v2/v3/v3.1. This is a breaking change, previously both cases were read as an empty list. also includes a change to OpenApiOperation.SerializeInternal so it can serialize these two cases separately. this required a new method OpenApiWriterExtensions.WriteOptionalOrEmptyCollection. includes unit tests, change to PublicApi.approved.txt to include the new method, and I removed a couple of unused usings and a typo in test name `SerializeDocWithSecuritySchemeWithInlineReferencesWorks`.

…crosoft#1426 make distinction between empty security requirements and no security requirements on an operation. empty security requirements are read as an empty list, no security requirements are read as null for OpenAPI v2/v3/v3.1. This is a breaking change, previously both cases were read as an empty list. also includes a change to OpenApiOperation.SerializeInternal so it can serialize these two cases separately. this required a new method OpenApiWriterExtensions.WriteOptionalOrEmptyCollection. includes unit tests, change to PublicApi.approved.txt to include the new method, and I removed a couple of unused usings and a typo in test name `SerializeDocWithSecuritySchemeWithInlineReferencesWorks`.

MaggieKimani1 added type:breaking-change An issue that will result in dependent client projects failing. type:bug A broken experience labels Nov 8, 2023

baywet added this to the v2-Preview12 milestone Feb 27, 2025

paulmendix linked a pull request Apr 13, 2025 that will close this issue

fix!: handle deserializing and writing empty security requirements #1426 #2323

Open

microsoft-github-policy-service bot added the WIP label Apr 13, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No difference between no security requirement and empty security requirement on Operations #1426

No difference between no security requirement and empty security requirement on Operations #1426

VisualBean commented Oct 11, 2023 •

edited

Loading

darrelmiller commented Oct 17, 2023 •

edited

Loading

VisualBean commented Oct 17, 2023 •

edited

Loading

crudbee commented Oct 18, 2023

corentinvds commented Oct 17, 2024

paulmendix commented Feb 5, 2025

darrelmiller commented Mar 12, 2025

paulmendix commented Apr 6, 2025

MaggieKimani1 commented Apr 11, 2025

paulmendix commented Apr 11, 2025

No difference between no security requirement and empty security requirement on Operations #1426

No difference between no security requirement and empty security requirement on Operations #1426

Comments

VisualBean commented Oct 11, 2023 • edited Loading

darrelmiller commented Oct 17, 2023 • edited Loading

VisualBean commented Oct 17, 2023 • edited Loading

crudbee commented Oct 18, 2023

corentinvds commented Oct 17, 2024

paulmendix commented Feb 5, 2025

darrelmiller commented Mar 12, 2025

paulmendix commented Apr 6, 2025

MaggieKimani1 commented Apr 11, 2025

paulmendix commented Apr 11, 2025

VisualBean commented Oct 11, 2023 •

edited

Loading

darrelmiller commented Oct 17, 2023 •

edited

Loading

VisualBean commented Oct 17, 2023 •

edited

Loading