[BUG] Can't use multiple security schemes / disable them

[commentator8]

Bug Report Checklist

• [v] Have you provided a full/minimal spec to reproduce the issue?
• [v] Have you validated the input using an OpenAPI validator (example)?
• [v] Have you tested with the latest master to confirm the issue still exists?
• [v] Have you searched for related issues/PRs?
• [-] What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request

Description

I initially encountered something very much like this, where when using the main openapi-generator I did not get attributes generated for my response (the attributes are required and with normal names e.g. password). I checked swagger-codegen and it worked fine, and I checked this repo's version and it worked also. I much prefer this version or openapi-generator as they have type hints and client side validation.

When trying to use this version (as the successor to openapi-generator) I encountered a couple of issues. I make use of two security headers ob_user_auth (passed as Authentication) and ob_m2m_auth (passed as User-Authentication). As far as I can tell the code doesn't allow for more than 1.

security_requirement_object = self.api_client.configuration.get_security_requirement_object(
    'paths/' + path + '/get/security',
    _security,
    security_index
)

where this code returns a specific security_requirement_object based on an index and security_index_info defaults to

self.security_index_info: SecurityIndexInfo = security_index_info or {'security': 0}

and even if i manually populated it (couldn't see how to easily) it returns an index and as such returns just the one APIToken possibility.

Furthermore, as opposed to the old version, I can't see how to disable the security headers without resorting to something like this:

security_scheme_info: api_configuration.SecuritySchemeInfo = {
    "ob_user_auth": ApiKeySecurityScheme('', '', in_location='fake'),
    "ob_m2m_auth": ApiKeySecurityScheme('', '', in_location='fake'),
}

used_configuration = api_configuration.ApiConfiguration(
    security_scheme_info=security_scheme_info,
)

since security_scheme_instance.apply_auth can't take a dict and there isn't a check for the headers not being set or any other disable method that I can see. This works because if in_location is not one of the if/elif it knows about it ignores it. Am i missing anything?

when i configure with security_scheme_info: api_configuration.SecuritySchemeInfo = {} i get this (only one header is sent):

send: b'GET /api/v1/basic/1ff033ca-bb4b-4b74-b45e-c34b1b2301ec?account_id=1ece138f-4fb0-4f8e-8256-a7edda655c04 HTTP/1.1\r\nHost: localhost:8004\r\nAccept-Encoding: identity\r\nUser-Agent: OpenAPI-JSON-Schema-Generator/1.0.0/python\r\nUser-Authorization: sampleApiKeyValue\r\nAccept: application/json\r\n\r\n'

In the old repo however if I configure it as follows:

configuration.api_key['ob_m2m_auth'] = 'm2m'

# Uncomment below to setup prefix (e.g. Bearer) for API key, if needed
configuration.api_key_prefix['ob_m2m_auth'] = 'Bearer'

# Configure API key authorization: ob_user_auth
configuration.api_key['ob_user_auth'] = 'user'

# Uncomment below to setup prefix (e.g. Bearer) for API key, if needed
configuration.api_key_prefix['ob_user_auth'] = 'Bearer'

it sends this

send: b'GET /api/v1/basic/1ff033ca-bb4b-4b74-b45e-c34b1b2301ec?account_id=1ece138f-4fb0-4f8e-8256-a7edda655c04 HTTP/1.1\r\nHost: localhost:8004\r\nAccept-Encoding: identity\r\nUser-Agent: OpenAPI-Generator/1.0.0/python\r\nAuthorization: Bearer m2m\r\nUser-Authorization: Bearer user\r\nAccept: application/json\r\n\r\n'

which is valid. And if I comment out those config lines it sends nothing - which is exactly what I need for dev environments.

Since the code changes between the repos are significant and you explicitly changed how you manage the security headers - I'm not sure if it is possible still. It might be easier to backport the fix from the issue i referenced above to the old repo for the meanwhile.

TLDR - i would like either to get the attributes working in the old repo or get the security controls able to be a) disabled on demand and b) send multiple auth headers. Is any of that possible?

Here is the script used to test, i could mock up a server if needed to test.

Thanks!

openapi-json-schema-generator version

Using the docker current version - couldn't easily get the internal version.

OpenAPI declaration file content or url

Gist

Generation Details

docker run --rm -v "${PWD}:/local" openapijsonschematools/openapi-json-schema-generator-cli generate \  
    -i /local/openapi.yaml \
    -g python \
    -o /local/token_client_new_openapi

Steps to reproduce

generate with the above gsit and use the following to send a request.

Related issues/PRs

Suggest a fix

[spacether]

Hi there. Thanks for using this project. Both of your requested use cases are possible and demonstrated in passing tests.
You are asking for

• multiple security information headers to be used when making a call
• no security info to be used when making a call

Per the spec

• multiple security schemas can be specified in one index in a security requirement object
• no security is defined as a value of empty object {}

When looking at these global security requirement definitions

security:
  - api_key: []
  - http_basic_test: []
  - {}
  - api_key: []
    http_basic_test: []
paths:

• index 2 defines no security - {}
• index 3 defines security with info from two security schemes:

  - api_key: []
    http_basic_test: []

Please check these tests, which show it working and are passing in CI:

• security index 2 sets no security headers
• security index 3 sets both headers

Action Needed

Please update your spec to contain two security requirements objects like I show above, one empty, and one with two security schemes

Point About Having Trouble Seeing How to Set Security info

where this code returns a specific security_requirement_object based on an index and security_index_info defaults to

self.security_index_info: SecurityIndexInfo = security_index_info or {'security': 0}

and even if i manually populated it (couldn't see how to easily) it returns an index and as such returns just the one APIToken possibility.

Note: I see that the endpoint docs are missing the security_index input. I will add it.

The docs for each endpoint show how to set up security_scheme_info like here:
https://github.com/openapi-json-schema-tools/openapi-json-schema-generator/blob/master/samples/openapi3/client/features/security/python/docs/paths/path_with_security_from_root/get.md#code-sample

Do you prefer that a commented out security_index_info example is also included?
Per the code this typeddict fully defines what is allowed in for security_index_info:

SecurityIndexInfo = typing_extensions.TypedDict(
    'SecurityIndexInfo',
    {
        'security': typing_extensions.Literal[0, 1, 2, 3],
        "paths//pathWithOneExplicitSecurity/get/security": typing_extensions.Literal[0],
        "paths//pathWithTwoExplicitSecurity/get/security": typing_extensions.Literal[0, 1],
    },
    total=False
)

[commentator8]

Hi, thanks for the (really) fast response! Appreciate you making the project ;)

I was using the openapi.yaml as generated by FastAPI - so hadn't considered modifying the output. To be honest, the old version of the project where you just comment out / don't specify the details for my existing yaml is much simpler - but I'll take it if it works :) When I change the security to be as described I indeed get 4 indexes in the _security object in operation.py, and can successfully specify both headers for the production use case 🥳 However unless I explicitly specify security_index=2 in the API call I get an exception as within get_security_requirement_object it falls back to using index 0 as per:

# fallback and use the default index
used_index = self.security_index_info["security"]

where that is defined as self.security_index_info: SecurityIndexInfo = security_index_info or {'security': 0}.

And I just edited away all my mistakes 😄 I figured out that I needed to supply security_index_info = {'security': 2} to the API configuration object and can achieve the desired effect.

That is the correct move - right?

Thanks again for the prompt responses!

[spacether]

Hi, thanks for the (really) fast response! Appreciate you making the project ;)

You're welcome 🙂

Why do you feel that the new way is more cumbersome? There are 2 ways to set the security_index_info.

1. specifically overriding it per endpoint call
2. or using the setting from your configuration.security_index_info.

If you use option 2, then you only set the security that you want to use once in one place.

• Do you want all endpoints to use this security? If so then define it globally and set the index in the config for it
• If you only want specific endpoints to use a specific security index, then again set it in the Configuration.security_index_info, which you set once.

{'security': 2}

Yes that's correct per the definition of 'security': typing_extensions.Literal[0, 1, 2, 3], which is what I describe above

[commentator8]

You couldn't have stated it clearer - I just finished editing my response (which accidentally got cmd+entered midway, sorry) - but now its crystal clear. I somehow failed to pick up on the goal of the 'security' default and expected that I need to either specify each separate endpoint there.

In retrospect it is clear that {'security': 2} achieves what I need. I might suggest that you document not just the security_index but also the security_index_info to make it clear that supplying the 'security' param will serve as the default. Perhaps even rename to default?

I wonder now if it was a quirk of swagger-codegen and openapi-generator that allowed

security:
- ob_user_auth: []
- ob_m2m_auth: []

to work, and in your version not. Yours seems the more explicit and correct, but the others are easier to use perhaps (if overly loose).

On an unrelated/related note - do you happen to know off the top of your head how to get fastapi to output the desired security format? Just asking since you know the other half of the coin, and if you use fastapi no harm asking :)

[spacether]

Let me think about a good way to document it. The security key refers to globally defined security indices.
One thing that I can do is make the security key a required key and get rid of the security_index_info.get(index, 0) fallback.

Also each endpoint does list its security_index values and it says where they come from (root or path security).
https://github.com/openapi-json-schema-tools/openapi-json-schema-generator/blob/master/samples/openapi3/client/features/security/python/docs/paths/path_with_security_from_root/get.md#security

I wonder now if it was a quirk of swagger-codegen and openapi-generator that allowed

security:
- ob_user_auth: []
- ob_m2m_auth: []

Per the spec that is defining a security scheme reference with no oauth scopes.
The list MAY be empty if authorization does not require a specified scope

But that is different from use no auth.

On an unrelated/related note - do you happen to know off the top of your head how to get fastapi to output the desired security format? Just asking since you know the other half of the coin, and if you use fastapi no harm asking :)

Not sure what you mean here. How about asking the author of that repo to update their spec to define security for routes that do not use security as {} in an issue?

Can you mark this issue as closed because the code does what you need it to do?

[commentator8]

Thanks for the help!

[spacether]

Just now I released v2.0.3 which includes updated docs that

• describe the security_index input
• include a code sample for security_index_info if there is > 1 security evailable

Code sample is here

security_index_info: api_configuration.SecurityIndexInfo = {
    "security": 0,
    # only set one "security": 1,
    # only set one "security": 2,
    # only set one "security": 3,
}
used_configuration = api_configuration.ApiConfiguration(
    security_scheme_info=security_scheme_info,
    security_index_info=security_index_info
)