Using in Vite/Vue3 App Throws 'Uncaught TypeError: util.inherits is not a function'

[mwoodward-atd]

When attempting to instantiate a Client object in a Vite/Vue3 app, the error Uncaught TypeError: util.inherits is not a function is thrown.

Environment

• Node 18.16

Steps to Reproduce

1. Create a new Vite/Vue3 app, install dependencies, and launch app

npm create vite@latest duo-vite-test -- --template vue
cd duo-vite-test
npm install
npm install @duosecurity/duo_universal
npm run dev

2. Instantiate Client in App.vue <script setup> block

import { Client } from '@duosecurity/duo_universal'

const client = new Client({
  clientId: 'theclientid',
  clientSecret: 'theclientsecret',
  apiHost: 'theapihost',
  redirectUrl: 'http://localhost:5173',
})

3. When the app reloads, the following error is thrown:

Uncaught TypeError: util.inherits is not a function
    at node_modules/jws/lib/data-stream.js (data-stream.js:39:6)
    at __require (chunk-OL3AADLO.js?v=606a3168:9:50)
    at node_modules/jws/lib/sign-stream.js (sign-stream.js:3:18)
    at __require (chunk-OL3AADLO.js?v=606a3168:9:50)
    at node_modules/jws/index.js (index.js:2:18)
    at __require (chunk-OL3AADLO.js?v=606a3168:9:50)
    at node_modules/jsonwebtoken/decode.js (decode.js:1:11)
    at __require (chunk-OL3AADLO.js?v=606a3168:9:50)
    at node_modules/jsonwebtoken/verify.js (verify.js:4:16)
    at __require (chunk-OL3AADLO.js?v=606a3168:9:50)
triggerError @ vue-router.mjs:3451
(anonymous) @ vue-router.mjs:3173
Promise.catch (async)
pushWithRedirect @ vue-router.mjs:3167
push @ vue-router.mjs:3099
install @ vue-router.mjs:3530
use @ runtime-core.esm-bundler.js:4381
start @ client-entry.js?t=1686682252177:120
await in start (async)
(anonymous) @ client-entry.js?t=1686682252177:165
Promise.then (async)
(anonymous) @ client-entry.js?t=1686682252177:163
Promise.then (async)
(anonymous) @ client-entry.js?t=1686682252177:139

[AaronAtDuo]

Looks to be similar/related to auth0/node-jws#101
also
https://stackoverflow.com/questions/70727494/why-cant-i-use-jwt-verify-from-jsonwebtoken-in-react

[mwoodward-atd]

Thanks @AaronAtDuo ! I'll take a look at that. Appreciate the reference.

[AaronAtDuo]

I'm looking through those myself. I'm not a Node and/or JS dev so bear with me :)

[AaronAtDuo]

It doesn't look like there's a great solution for this, but maybe the best one is to introduce some sort of polyfill to work around this?

[mwoodward-atd]

Thanks @AaronAtDuo -- that's what we've found so far as well, so we'll dig into that angle a bit more.

[lukashroch]

Stumbled upon this one recently too.

Could be fixed with swapping oldish jsonwebtoken lib with newer, though heavily used/tested jose lib, which is CJS/ESM and treeshakable, written for lot of environments, doesn't have any node specific deps.

If maintainers are OK with the idea (@AaronAtDuo ?) I could prepare a PR to swap the JWT libs and probably update the build process to make this lib both CJS/ESM compatible.

Though, I think there are still few node.js specifics in this lib too, which would need tackling (maybe later) to make this fully env-independent for both node and browsers. Alternatively, those can be handled with vite polyfill plugin.

[danhickman]

@lukashroch, have you had any luck getting Duo to take your pull request? I'm having a hard time getting this to work with Vite and I'm hoping your fork will fix things. Any thoughts on publishing your esm branch as a public package so it can be used directly?

[lukashroch]

@danhickman unfortunately no, there was no comment there from Duo. I could potentially publish it as fork, but I'd like to avoid this if possible as I actually created this initial node.js implementation and then duo guys reached out that they would like to maintain it as official lib so I handed the reins over to them. So hopefully they are still maintaining it, just didn't notice that PR.

I just bumped the PR, hopefully @jeffreyparker / @AaronAtDuo or someone from Duo will comment, but I'm not sure who is current maintainer as there doesn't seem to be much recent activity.

[AaronAtDuo]

Taking a look

[danhickman]

@danhickman unfortunately no, there was no comment there from Duo. I could potentially publish it as fork, but I'd like to avoid this if possible as I actually created this initial node.js implementation and then duo guys reached out that they would like to maintain it as official lib so I handed the reins over to them. So hopefully they are still maintaining it, just didn't notice that PR.

I just bumped the PR, hopefully @jeffreyparker / @AaronAtDuo or someone from Duo will comment, but I'm not sure who is current maintainer as there doesn't seem to be much recent activity.

@lukashroch thanks for your response. I have your branch working with some tweaks and including the distributable in my project but having to make a number of updates to make it work with my Vite build. There are issues with Node.js library dependencies including "crypto" and "https". Also it's not clear why Axios is needed. Can't you make the http calls using standard XHR? I see it's referencing a certificate but it's unclear why those are needed. Seems to work fine for me when I remove the https.Agent reference which is where the certificate is referenced. I'd really like to see a version that is targeted at browsers and not native Node.js. Possible?

[lukashroch]

Yeah, as I mentioned in my first comment a bit up, there are still few node.js specifics, which were are not covered in the PR. I guess aim would be to have a version both compatible for node.js and browser or export separate versions?

PR was meant as first step to bump the build system to cjs/esm compatible builds while removing couple of obvious/not-needed node.js deps like jsonwebtoken + node:fs/path reported in this issue.
Next step could be to tackle the rest (crypto/https). I didn't want to bundle all the in one go to same PR as the lib still needs the http/crypto functionality in a sense that it needs to 1) call http and 2) generate some random strings.

There are few options how to tackle it, use libs like (axios) so get things bundled in not to rely on runtime (node.js vs browser) but in expense of larger build size. Or use what's native in runtimes, but it needs tackling that in code so it checks what's available like fetch or crypto from node.js vs browser.

I'm not sure why the cert was included explicitly though, that would be a question for maintainers. IMO it shouldn't be strictly needed as it should be able to pull OS CAs.

[lukashroch]

@danhickman I've replaced couple of more node std libs with access through globalThis in PR. think the only issue should be the httpsAgent now, which we'll need insight from maintainers if it's needed to use custom CA. if not there could just be a check to enforce https protocol on redirect URI.

[danhickman]

@danhickman I've replaced couple of more node std libs with access through globalThis in PR. think the only issue should be the httpsAgent now, which we'll need insight from maintainers if it's needed to use custom CA. if not there could just be a check to enforce https protocol on redirect URI.

@lukashroch thanks for the update. After digging into the library further I realized that I could use the C# library on the server and communicate the auth URL to the client so I've gone that route. Thanks for your attention and good luck getting things updated.

[AaronAtDuo]

if it's needed to use custom CA

The directive from our application security teams is that we must enforce certificate pinning if possible. So whatever we use has to support that use case. I don't have any personal preference though, if some other http client would work better but still support the pinning, we can consider switching.