[Python]Client library does not generate auth_settings with multiple definitions

[ianseyer]

Description

I am using swagger-codegen to generate a python client library based on a spec with multiple security definitions. The generated library is both not generating all the security definitions, and doesn't even attempt to use the one that was generated.

Security definitions in configuration.py. Note the lack of "knurld_auth" OAuth definition:

    def auth_settings(self):
        """
        Gets Auth Settings dict for api client.

        :return: The Auth Settings information dict.
        """
        return {
            'developer_id':
                {
                    'type': 'api_key',
                    'in': 'header',
                    'key': 'Developer-id: Bearer:',
                    'value': self.get_api_key_with_prefix('Developer-id: Bearer:')
                },

        }

Contents of all methods in api_client.py indicate no security definition being used:

# Authentication setting
        auth_settings = []

Swagger-codegen version

2.0

Swagger declaration file content or url

https://gist.github.com/ianseyer/f3610a13702aaee9dd4b2d804222512f

The relevant part:

  "securityDefinitions": {
    "developer_id": {
      "type": "apiKey",
      "name": "Developer-id: Bearer:",
      "in": "header"
    },
    "knurld_auth": {
      "type": "oauth2",
      "authorizationUrl": "https://api.knurld.io/oauth/client_credential/accesstoken?grant_type=client_credentials",
      "tokenUrl": "https://api.knurld.io/oauth/client_credential/accesstoken?grant_type=client_credentials",
      "flow": "application"
    }
  }

Command line used for generation

swagger-codegen generate -i swagger.compiled.json -o python/ -l python

Steps to reproduce

Download swagger spec, generate, browse the source.

Suggest a Fix

Check for proper definitions within swagger-codegen. No errors or warnings were thrown.

[wing328]

@ianseyer you're not defining the security correctly. Here is a correct example: https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/test/resources/2_0/petstore.json#L210

(array of string vs array of hash)

[ianseyer]

So that gets me closer.
(A note: I still get the erroneous issue of the definitions not being created for the python client, in the same fashion as #3366, but the ruby client does generate both).

It now correctly associates and creates the security definitions.

However, the authorizationURL exists nowhere but in the code, except in the ReadMe, implying that the client itself does not fetch the access token using the client_id/client_secret combination.

Is this correct behavior?

[wing328]

@ianseyer I don't think the python client can automatically refresh the token via authorizationURat the moment.

If you're aware of any python lib to do that or you want to contribute the enhancement, let me know and I'll show you some good starting points.

cc @scottrw93

[ianseyer]

Well, I see one solution as simply using the decorator method for api_client functions that checks against a timer to see if the previously retrieved token is still valid. If the stored token is valid, then package it into the header. If not, make the request to the authorizationURL and start the timer over.

And then, for any paths that call for that OAuth security method, wrap the call in that decorator.

Out of curiosity, do ANY of the client libraries support this? I don't even see the client attempt to get a token to begin with.

[fehguy]

I really think that refreshing tokens is out of scope for an auto-generated client. You should write a thin layer on top of the client to do that.

[ianseyer]

For what reason? Not trying to be argumentative, just curious.

My take: token refresh rates and exchanges are baked into the OAuth spec - i.e. if a client "supports" the spec, it supports refreshing tokens.

I don't see why each developer for each client would want to/need to rewrite this code. For example, a big reason behind my usage is that I am trying to generate client libraries for languages that I am not competent enough to write myself. I don't know the best development strategies for every language, and see swagger as a simple way of giving people a great starting place to use an API in a language of their choice. Having to implement a refresh token using some sort of decorator pattern would be out of my knowledge in a litany of languages, which would completely bar the SDK from usage.

[fehguy]

No problem at all--driver usage varies a ton between applications. For a shared client, for example, keeping state of tokens in the client SDK is a very bad idea, and thus handling the token refresh would be problematic.

[ianseyer]

It seems to me that that is an edge case, whereas the majority of uses would benefit from the implementation. It could be, even, a flag for the generator.

[ianseyer]

And if anyone could give me some feedback on #3366 that'd be great too :)

[fehguy]

it's quite common, to avoid re-initializing clients. However, if you're seeing this in regular client SDK practice, please share a pointer to it and maybe we can learn something from it.

[ianseyer]

Dropbox sets the token per client instance using a client_id/client_secret exchange, stored on the running machine:
https://github.com/dropbox/dropbox-sdk-python/blob/master/dropbox/oauth.py#L370

The boto3 (AWS) SDK also handles the exchange of id & secret: https://github.com/boto/boto3