Allow custom router-level middleware

[b055man]

Currently the connector wraps the whole router-level logic and allows only minor changes to it - by means of the security middleware.
However, it'd be great if you enable option for passing an arbitrary middleware that requires to work on a router-level (https://expressjs.com/en/guide/using-middleware.html#middleware.router) - as it is in case of e.g. express-ajv-swagger-validation module: https://www.npmjs.com/package/express-ajv-swagger-validation

From the connector perspective, it can be as easy as adding a single line:
if (opts['customMiddlewares']) descriptor.push(opts['customMiddlewares'])

[davesag]

Interesting suggestion @b055man — I'll take a look over the weekend.

[davesag]

Having looked into this I believe you can achieve what you want either by just creating the router object for a specific api.yml file and passing that into the connect function in your server startup script. The downside to that is you need multiple api.yml files for each part of the router. I might need to make some code changes to allow use of multiple files however.

The other alternative is to add a 'x-use-router' variable in the api.yml definition and let It manage the creation of router objects based on the settings in that.

I'd rather you considered the first option as a fill-in measure while I look further at all the implications of the second option.

[davesag]

Hi @b055man

I believe I misunderstood your request now I've looked at this. Are you after the ability to define custom middleware on a route by route basis?

In which case I propose supporting an OpenAPI Specification Extension in the form x-middleware as follows

paths:
  /some-route:
    get:
      summary: 'some summary'
      security:
        - apiKey: []
      x-middleware:
        - customMiddleware

Then the descriptor would end up being

[path, apiKeyMiddleware, customMiddlewareHandler, handler]

You'd need to pass in the middleware via the options:

const options = {
  middleware: {
    customMiddleware: customMiddlewareHandler
  }
}

Would that suit your needs?

[b055man]

Hi @davesag,

yes, that's something I was thinking about. One thing though: could customMiddleware be an array, with an ordered list of middlewares?

A.

[davesag]

Hey @b055man yes sure, though the order of the middleware would be the order defined in the OpenAPI.yml or swagger.yml not the options as the options are just there as a lookup. For example if your api is defined as

paths:
  /some-route:
    get:
      summary: 'some summary'
      operationId: handleSomeRoute
      security:
        - apiKey: []
      x-middleware:
        - doThis
        - doThat

Then your options contain

const options = {
  middleware: {
    doThis: thisDoerFn,
    doThat: thatDoerFn
  }
}

then the descriptor for the route will be

['/some-route', apiKey, thisDoerFn, thatDoerFn, handleSomeRoute]

So the security middleware will always come before any custom middleware

[b055man]

Yes, that's understandable.
So, I assume you are planning to introduce this functionality?

Thanks,
A.

[davesag]

@b055man yep. I'll add it as part of the Version 2.1 release. (It could probably be done before that if you have an urgent need for it).

[davesag]

Hey @b055man this is now done and was merged in with PR #33

I am just waiting on the new release of mocha with the fix for the security audit issue before I publish a new version. I'll do that as soon as mocha is updated.

[davesag]

Hi @b055man this feature is now available in version 2.1.0. Thanks for your suggestion.

[b055man]

@davesag thanks a lot. I'll give it a try after the weekend.