-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Standardize behaviour of no_proxy environmental variable #1223
Conversation
packages/http-client/src/proxy.ts
Outdated
@@ -51,7 +51,7 @@ export function checkBypass(reqUrl: URL): boolean { | |||
.split(',') | |||
.map(x => x.trim().toUpperCase()) | |||
.filter(x => x)) { | |||
if (upperReqHosts.some(x => x === upperNoProxyItem)) { | |||
if (upperReqHosts.some(x => x.includes(upperNoProxyItem))) { |
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 it would be safer to use endsWith
instead of includes
to avoid bad actors from bypassing the proxy. For example if we set no_proxy=mycompany.com
then a domain like mycompany.com.evil.org
should not bypass the proxy.
if (upperReqHosts.some(x => x.includes(upperNoProxyItem))) { | |
if (upperReqHosts.some(x => x.endsWith(upperNoProxyItem))) { |
The above would still let domains like evilmycompany.com
bypass the proxy. Perhaps a better formulation would be
if (upperReqHosts.some(x => x.includes(upperNoProxyItem))) { | |
if (upperReqHosts.some(x => x === upperNoProxyItem || x.endsWith('.' + upperNoProxyItem))) { |
In addition we might want to strip off a leading .
to ensure that no_proxy=example.com
and no_proxy=.example.com
are treated the same.
I think the following should work:
// Compare request host against noproxy
for (const upperNoProxyItem of noProxy
.split(',')
.map(x => x.trim().toUpperCase())
.map(x => x.charAt(0) === '.' ? x.substr(1) : x)
.filter(x => x)) {
if (upperReqHosts.some(x => x === upperNoProxyItem || x.endsWith('.' + upperNoProxyItem))) {
return true
}
}
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.
+1 for @aibaars suggestions too, ensWith + '.' sounds good
NIT: I'd consider a small refactoring of the block from line 54, it's becoming a bit dense with filters
@felixlut Could you add a test-case that covers the change in https://github.com/actions/toolkit/blob/main/packages/http-client/__tests__/proxy.test.ts ?
PS the PR validation currently fails due to some older packages, I'll take a look in a different PR
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 like your suggestions, and sure I can add a test-case. I'll try to find time over the weekend!
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've implemented the suggested changes (in addition to some other suggestions from the article I posted above), as well as test-cases for each of them. Namely the following was added:
*
matching all hosts- Strip leading dots (
.domain.com
-->domain.com
)
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 looks good to me. @fhammerl , could you have a look at this?
@fhammerl We also need to make the |
@TingluoHuang |
No |
Haven't seen any activity in here for a couple of days. Just checking, there is nothing I should do now? This PR is just blocked until #1230 is merged? |
1 similar comment
Haven't seen any activity in here for a couple of days. Just checking, there is nothing I should do now? This PR is just blocked until #1230 is merged? |
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.
Great tests, thanks for the refactoring too.
LGTM
We're holding off with merging it for now as the 'audit' check is failing.
We'll fix that first on main, then merge this branch.
@fhammerl any update? |
We're migrating the project over to Node16, will merge this PR right after. |
Could you please reference the PR for that migration so that people waiting for this can track the progress? |
@felixlut Would you mind committing one more time so that our checks can re-run? Once those clear we can get this ready to merge. |
@vmjoseph Any update on this? |
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.
Looks like there's a linting error.
This reverts commit 0e925a6.
Hey @felixlut We'd like to follow the no_proxy system we've established in actions/runner The runner rules today:
This would bring the behaviour to that of With those changes, I can get this PR merged ASAP. Let me know if that works for you |
Sounds good to me, as you say, the subdomains was the reason i opened this! I can make the required rollbacks later tonight, or more likely tomorrow! |
const bypass = pm.checkBypass(new URL('https://anything.whatsoever.com')) | ||
expect(bypass).toBeFalsy() | ||
}) | ||
|
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.
Can We add one more test to chech a subdomain is supported when no_proxy has a leading dot?
it('checkBypass returns true if host with subdomain in no_proxy defined with leading "."', () => {
process.env['no_proxy'] = '.myserver.com'
const bypass = pm.checkBypass(new URL('https://sub.myserver.com'))
expect(bypass).toBeTruthy()
})
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.
Ye sure!
Another question also, since you want the no_proxy
to be the same as in the actions/runner
, do you also want me to re-structure the code to be more similar to how they handle it (see ref)?
Obviously it's not the same language, but might be easier to keep consistency between them if they are implemented using the same logic, just with different languages.
Might be overkill, but I'm willing to do it if that makes it easier maintainable for you guys!
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'd prefer to keep PRs for the functional changes and refactoring changes separate, but really appreciate you asking 👍
Also, here's a good set of unit tests from the runner code if needed
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''ve added the test you wrote, as well a new one for checking partial domains (such that no_proxy=myserver.com
won't let evilmyserver.com
through).
This required some extra logic
@felixlut Thanks again for this, I'll ping you as we publish it 👍 |
The behaviour of the
no_proxy
environmental variable is famously inconsistent, but this change should follow how it usually works (i.e., thatno_proxy=domain.com
matches its subdomains, such assome.domain.com
).Resolves #1172