Fix password and username in http.url

[Dorcas-BD]

Which problem is this PR solving?

This PR addresses the issue described in #2000 which states that the http.url attribute must not contain credentials passed via the URL. According to the recent specification changes, URLs formatted as https://username:[email protected]/ are invalid for the http.url attribute and should instead be formatted as https://www.example.com/.

Fixes #2000

Short description of the changes

The isValidOptionsType function has been modified to check for the presence of credentials in a given URL using the url.parse method. If the URL contains authentication information (i.e., username or password), the function will return false. Conversely, the function will return true if the URL contains no credentials.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

The functionality has been tested with a series of unit tests, which include various input values. The tests verify that the function returns false for invalid URLs containing credentials and true for valid URLs and acceptable types such as strings and objects. The test cases ensure the behaviour is consistent with the updated requirements.

describe('isValidOptionsType()', () => {
  [
    '',
    false,
    true,
    1,
    0,
    'https://username:[email protected]/',
    [],
  ].forEach(options => {
    it(`should return false with the following value: ${JSON.stringify(
      options
    )}`, () => {
      assert.strictEqual(utils.isValidOptionsType(options), false);
    });
  });
  for (const options of ['url', url.parse('http://url.com'), {}]) {
    it(`should return true with the following value: ${JSON.stringify(
      options
    )}`, () => {
      assert.strictEqual(utils.isValidOptionsType(options), true);
    });
  }
});

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Dorcas-BD / name: Dorcas Bamisile (edff381, 5a09d95, eb92213, 148ae39)

[JacksonWeber]

You may want to update this function description to better represent the new logic added in this PR.

[Dorcas-BD]

Okay, thanks

I will do that

[david-luna]

According to https://nodejs.org/api/url.html#urlparseurlstring-parsequerystring-slashesdenotehost this line could throw and also is discouraged due to security issues. The replacement would be then URL.parse but it won't be available in Node.js versions prev to v22.1.0. Maybe this could be extracted in to a utility function

function parseUrl(input: string): URL | null {
  if (URL.parse) {
    return URL.parse(input);
  }
  try {
    return url.parse(input);
  } catch {}
  return null;
}

and use it here

[Dorcas-BD]

Thanks for the feedback! I’ll extract the logic into a utility function to handle the compatibility and update the PR shortly.

[legendecas]

I think the util function should be as follows, avoid using the deprecated url.parse:

// This is identical to `URL.parse`.
function parseUrl(input: string, base?: string): URL | null {
  try {
    return new URL(input, base);
  } catch {}
  return null;
}

[pichlermarc]

@david-luna @legendecas this was recently the source a of a bug report #5060 - I opened a PR #5091 that may conflict with this PR. url.parse() and new URL() are different enough that replacing url.parse() was quite the headache, I'd appreciate a review 🙂

[david-luna]

@legendecas using the constructor seems a better solution in terms of version support :)

isValidOptionsType will inspect the returned URL object to decide if the param is valid or not. So if null is returned (new URL() throws) I guess the author of this PR would make the function fallback to checking the type (string or object). There is another situation that will throw an error which is if the instrumentation is running on a Node.js version earlier than v18.17.0 where the URL constructor is not available.

This means for Node.js <v18.17.0 all strings will be considered valid so for these versions the fix wont apply. I wonder if it's okay to have this partial fix/support 🤔

[david-luna]

This means for Node.js <v18.17.0 all strings will be considered valid so for these versions the fix wont apply. I wonder if it's okay to have this partial fix/support 🤔

I withdraw this part. I looked in the wrong place in the documentation. The new URL constructor is available and @legendecas solution is the way to go.

[legendecas]

The request was if there are credentials in the URL, redact the credentials and create the span (see note [4] at https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md). However, this change prevents spans from been created if the url contains credentials.

[Dorcas-BD]

Noted @legendecas , I will make the necessary adjustments.

Thank you