Honor auth option

[enekid]

Description

The WebSocket client documentation states that all standard http.request() options are valid.

Any other option allowed in http.request() or https.request().

But if you create a new WebSocket client, the auth property in the options object parameter is ignored. And the auth property is a valid http.request() options

Reproducible in:

• version: all versions

Steps to reproduce:

1. Create a Websocket client with an auth option:

const auth = 'user:password';
const ws = new WebSocket('ws://localhost', {auth});

Expected result:

The server should receive the auth header. Eg: Authorization: Basic dXNlcjpwYXNzd29yZA==

Actual result:

No auth header is sent.

Fix

When the opts object gets initialized, the auth property is set to undefined, overwriting the value passed in the options object.

A little reordering of the properties in the initialization seems to fix the bug.

[lpinca]

Thanks but this is by design. The auth option should not override the userinfo in the connection URL.

const ws = new WebSocket('ws://foo:bar@example.com/', { auth: 'baz:qux' });

foo:bar should win.

This is why other options like path, port, host, etc are also set to undefined. The values read from the parsed connection URL should not be changed by http.request() options.

[enekid]

Hi!

The userinfo will always win!

In the initAsClient function, after initiating the opts object with the options object,

  const opts = {
    protocolVersion: protocolVersions[1],
//...
    auth: undefined, // this line could even be deleted (?)
    ...options,
//...
  };

it's checked if there is userInfo in the parsedUrl, and if so, the auth property would be overwritten

  if (parsedUrl.username || parsedUrl.password) {
    opts.auth = `${parsedUrl.username}:${parsedUrl.password}`;
  }

[lpinca]

Ok, in that case I'm fine with this.

[lpinca]

Thank you.