-
Notifications
You must be signed in to change notification settings - Fork 8
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
update: fix async-app app chaining when mounting sub app #45
base: master
Are you sure you want to change the base?
Conversation
if (context.method === 'use') { | ||
return args; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a little bit too eager — one other solution would be to make isMiddleware
return false
whenever we send a App
instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine!
cd0a7c7
to
7df9e5f
Compare
When mounting a sub app with `app.use(path, subApp)`, express does a check to see if an app was sent through, or if it was a middleware. In async-app, we are converting all MiddlewareArguments which confuses express to think that the mounted app isn't an sub application, but a simple middleware. Thus, express doesn't fire the `mount` event, which in turns skips a bunch of express routines: - sets the `mountpath` on the subApp - copy some settings from the parent app (for instance "trust proxy") With this change, we can now use `req.app.path` to get the full route the request was matched for, and `req.ip` will be properly propagated through.
c513aef
to
64ab37a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing finding!
Scenario: mounted apps (nest level 1) | ||
Given app setting "trust proxy" is enabled | ||
Given the request header X-Forwarded-For is "1.1.1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NITPICK:
Given the request header X-Forwarded-For is "1.1.1.1" | |
And the request header X-Forwarded-For is "1.1.1.1" |
Scenario: mounted apps (nest level 2) | ||
Given app setting "trust proxy" is enabled | ||
Given the request header X-Forwarded-For is "10.0.1.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NITPICK:
Given the request header X-Forwarded-For is "10.0.1.3" | |
And the request header X-Forwarded-For is "10.0.1.3" |
if (context.method === 'use') { | ||
return args; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine!
onTearDown, | ||
}) => { | ||
// === App setup === // | ||
Given('app setting "(.*)" is enabled', (setting) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NITPICK: I would refer this step for enabling a setting for a specific app
Given('app setting "(.*)" is enabled', (setting) => { | |
Given('the (advanced|basic) app setting "(.*)" is enabled', (setting) => { |
When mounting a sub app with
app.use(path, subApp)
, express does a check to see if an app was sent through, or if it was a middleware.In async-app, we are converting all MiddlewareArguments which confuses express to think that the mounted app isn't an sub application, but a simple middleware.
Thus, express doesn't fire the
mount
event, which in turns skips a bunch of express routines:mountpath
on the subAppWith this change, we can now use
req.app.path
to get the full route the request was matched for, andreq.ip
will be properly propagated through.