`Issuer.discover` fails in nodejs process running within an electron window

[stagefright5]

Describe the bug

• Our application is an electron (v13) application
• It spawns a window that has nodejs integration
• In that process, we are using this (openid-client) module
• When Issuer.discover is called, it throws the following error

  stack: TypeError [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type function. Received an instance of Object
  at checkListener (events.js:112:11)
  at ClientRequest.once (events.js:435:3)
  at new ClientRequest (_http_client.js:202:10)
  at request (https.js:313:10)
  at Function.request (${PROJECT}\\node_modules\\openid-client\\lib\\helpers\\request.js:119:73)
  at Function.discover (${PROJECT}\\node_modules\\openid-client\\lib\\issuer.js:171:36)
  at AuthenticationService.getInstance (${PROJECT}\\core\\services\\AuthenticationService.js:43:39)

  Analysis

• In a pure nodejs process, the following is true

  require('url').URL === globalThis.URL // outputs true

• But, in nodejs process that is running within an electron window, the above code statement is false
• globalThis.URL is not the same as require('url').URL
• globalThis.URL refers to window.URL which is chromium implementation
• But, require('url').URL refers to nodejs implementation. So,

  require('url').URL === globalThis.URL // outputs false

• Because of this, in an electronWindow + nodejs environment, the URL instance that is being passed for (http || https).request method in helpers/request.js is NOT nodejs's URL instance
• After inspecting require('https').request method, I found that, it is compatible with ONLY nodejs's URL instance

Proposed Solutions:

1. Add the below require statement to the top of helpers/request.js module

   const { URL } = require('url')

   • This is how nodejs's https module has also implemented (ref: https://github.com/nodejs/node/blob/73d23a20a46e82299964cb1a4eaadaacac9b1de3/lib/https.js#L51)
2. Or, pass url parameter as string (url.href) instead directly passing url object to the (http || https).request method.
   • This will prevent any interference with nodejs, because, when the url is string, the request method will create a url instance as it needs

To Reproduce

Issuer and Client configuration: (inline or gist) - Don't forget to redact your secrets.

// NOT RELEVENT

Steps to reproduce the behavior:

1. Run nodejs process within an electron window with nodeIntegration enabled
2. Use Issuer.discover API
3. See it fail with the above mentioned error

Expected behavior

• This modules should behave the same in pure nodeJs and electron+nodejs environments

Environment:

• openid-client version: 5.1.6
• node version: 14.16.0

Additional context Add any other context about the problem here.

• [x] the bug is happening on latest openid-client too.
• [x] i have searched the issues tracker on github for similar issues and couldn't find anything related.

[panva]

Would you mind creating a small repro project? And also feel free to open a PR, don't forget tests.

[snowflake752]

Would you mind creating a small repro project? And also feel free to open a PR, don't forget tests.

Opened this PR https://github.com/panva/node-openid-client/pull/501, and all the tests are passing.

[panva]

Would you mind creating a small repro project? And also feel free to open a PR, don't forget tests.

Opened this PR #501, and all the tests are passing.

And the reproduction project?

[cjcooper]

I am surprised more haven't hit this issue. A call const issuer = await Issuer.discover('http://localhost:4011'); is causing this very issue. simple node & express, typescript application. Using step debugging it is this line: (url.protocol === 'https:' ? https.request : http.request)(url.href, opts);. I read the node documents and that should select the other overload of http but instead its choosing the first overload so opts is being viewed as a callback. the only way i could get it to stop doing that was removing '.href'. That caused node to use the correct overload of the method and it operated as expected. the docs absolutely state the "url" param can be a string or URL object but node is also not adhering to that. this is happening with node v16.16.0 and v16.17.0.