How can I tell swagger-codegen to reflect my api key?

[Stefan Schröder]

I define my swagger.json like this

<code>
{ "swagger": "2.0",
    "info": {
        "title": "title",
        "description": "desc",
        "version": "1.0"
    },
    "host": "myhost",
    "basePath": "mybasepath",
    "schemes": [
        "https"
    ],
    "produces": [
        "application/json"
    ],
    "security": [{
            "api_key": []
        }],
    "securityDefinitions": {
        "api_key": {
            "type": "apiKey",
            "name": "key",
            "in": "query"
        }
    },
    "paths": { ...
</code>

The validator says that it is a valid spec. With the above security definitions I want to make sure that each and every endpoint can only be called with a valid api key.

I generate a java client with

<code>
java -jar swagger-codegen/modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i myJson.json -l java -o myOutput
</code>

Everything works quite well. However, the resulting java client does not seem to give the client a way to set a valid api_key before for example posting smth to the server.

Did I miss something important here?

[OldSmokeySF]

I'm not sure that this spec (while valid) will impact any subsequent operation-declarations, or modify their 'parameters' lists ... you may have to declare the 'apiKey' in each 'parameters' list for each operation-declaration (in the 'paths' section) ... you can do that via a $ref to your 'securityDefinitions' in the 'parameters' list, and it works fine with codegen .. like this, for example:

put: 

{

• summary: "Do something requiring an apiKey",
• description: "Do something requiring an apiKey.",
• parameters: 

  [

  • {

    • $ref: "#/definitions/securityDefinitions"

    }

[Peter]

Interesting.

Could I assume that this will be done in a future version of swagger?

And if so, will it clash with a swagger file using the explicit definition?

How are people handling authentication for none-JS clients at the moment?

Peter

[Peter]

Hi,

as I needed that too I tried that but couldn't reuse the securityDefinition as the swagger editor reported that it is invalid. So I'm using now separate definitions for security and for the query parameter (is that intended?).

But the main problem is now that the JS client is no longer working. It says 'missing parameter: key' although I do

this.api.clientAuthorizations.add("apiKey", new SwaggerClient.ApiKeyAuthorization("key", key, "query"));

What could be wrong here? And how would you handle the api key authentication accross the clients?

Regards,

Peter

PS: is anyone really recommending to use swagger JS in production for its customers? It is 200KB large and that is the minified version...

[OldSmokeySF]

I'm using swagger-codegen with Java, and use the approach I detail in my reply earlier, it works fine.

[tony tam]

Hi, you would use api.getInvoker().addDefaultHeader("key", "value") to do this.  The client does not, however, determine *when* to apply the header (that's why it's called "defaultHeader").  They are sent on each request.

On Thursday, April 23, 2015 at 11:28:27 PM UTC-7, Stefan Schröder wrote:

[tony tam]

Hi Peter, your spec looks good, there was a bug in the swagger-js client where it was not honoring "top-level" security definitions like you have.  You can either grab the latest from github develop_2.0 branch or add the security definition on each operation.

[Peter]

Hi Tony,

ok, I'll try again with latest develop_2.0 (is this more recent than master?)

> you would use api.getInvoker().addDefaultHeader("key", "value") to do this. 

I need the API key in the query, so I fear this won't help me (?)

Regards,

Peter

[tony tam]

Yes, develop_2.0 is the in-progress development branch.  Master is the release.

Regarding the api key being a query string--please file a ticket in the repo so we can get that added.

https://github.com/swagger-api/swagger-codegen/issues

[Stefan Schroeder]

Thank you so much for your valuable answers. It helped.

Best,
Stefan

Am 24/04/15 um 21:29 schrieb tony tam:

--
You received this message because you are subscribed to a topic in the Google Groups "Swagger" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swagger-swaggersocket/A9oEdGP1Hzs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.