Better Explanation for Security Middleware Section

[Leyart]

I cannot make the "Security Middleware" work for my specification. My security definition is the following in YAML:

securityDefinitions: myauth: type: oauth2 authorizationUrl: "http://api.mywebsite.com/oauth/dialog" flow: implicit x-authorize: "authorize" scopes: "write:user": "modifies users' information" "read:user": "reads users' information" "write:request": "needed to write requests on the server" "read:request": "authorization to read requests on the server" "read:driver": "reads drivers' information" "write:driver": "modifies drivers' information"

But I don't think I have added properly the x-authorize parameter.

What does "an appropriate authorize function exists (defined using x-authorize in the securityDefinitions as per swaggerize-routes)" mean? Could it be explained in a detailed way, possibly with an example? Thank you in advance,

Luca

[tlivings]

Noted. Will add more detail.

Basically, x-authorize should point at a path to a file that exports a single middleware (in the case of express) function.

[Leyart]

The latest version of Generator Swaggerize is not using the proper swaggerize-express version. Part of my issues were due to this.

[tlivings]

Yes - I mis-published something! Corrections coming.

[talvor]

The path to the security function, is this relative to the project root, or to the API path?

[subeeshcbabu-zz]

The path is relative to the project root. https://github.com/krakenjs/swaggerize-routes/blob/master/lib/buildroutes.js#L161

[djMax]

What's the theory behind sticking project specific auth information into a swagger doc? I wouldn't want to expose that path in the external swagger doc, and I don't really want two separate docs for a single service right?

[tlivings]

Yeah, probably makes sense to filter out x- vendor extensions from the exposes API definition.

[djMax]

That's one option, but I'd vastly prefer being able to pass in named authorization handlers to the swaggerize function, because I don't like the idea of embedding "function calls" in what feels like an external facing API document... I'm not saying my approach is the only one, but it seems "reasonable." :)

[djMax]

In the meantime, essentially I just load the JSON swagger doc myself and inject the authorization function into the securityDefinitions before passing to swaggerize.

[tlivings]

Yeah might make sense to pass securityDefinitions as an explicit option so it isn't even in the document. Or pass named auth handlers.