-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow custom router-level middleware #22
Comments
Interesting suggestion @b055man — I'll take a look over the weekend. |
Having looked into this I believe you can achieve what you want either by just creating the The other alternative is to add a 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. |
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 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 const options = {
middleware: {
customMiddleware: customMiddlewareHandler
}
} Would that suit your needs? |
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. |
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 |
Yes, that's understandable. Thanks, |
@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). |
[Feature, #22] add path-specific middleware
Hey @b055man this is now done and was merged in with PR #33 I am just waiting on the new release of |
Hi @b055man this feature is now available in version 2.1.0. Thanks for your suggestion. |
@davesag thanks a lot. I'll give it a try after the weekend. |
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'])
The text was updated successfully, but these errors were encountered: