Just want to alert on this seemingly out-of-request type error in auth0
Did 0.50.0 affect auth0? read the docs and seemed like no
api | TypeError: Cannot read properties of undefined (reading ‘getPublicKey’)
api | at /Users/mtponte/twodots/voi/node_modules/@redwoodjs/api/dist/auth/decoders/auth0.js:57:29
api | at _node_internal (node:util:281:10)
api | at processTicksAndRejections (node:internal/process/task_queues:83:21)
Hi @twodotsmax I just tried the Auth0 example we have in The Playground Auth test too we have for Auth0 and I was able to login:
And confirm this is using v0.50:
Is this new behavior or the first time setting up Auth0?
So, this is a non critical error, everything seems to work fine, I just noticed this message was issued randomly one time in the console, which may point to some minor auth0 bug
Thanks for reporting, @twodotsmax, and thanks for tagging me @thedavid. I’ll take a look to see what’s going on.
We’re also seeing this error now too. For some reason, it tends to happen in burst for us, but it’s affecting quite a few calls to the back end now. We’re on version 0.48
We’re seeing 10-100 calls an hour end with the error:
{
"deploymentId": "dpl_4xtBDPTaauCLKjS95d24zuY7Vhfv",
"host": "core-g9b53d65i-buildpass.vercel.app",
"id": "1649201843107916034332372403",
"message": "START RequestId: 63555b90-79de-4937-bd26-f0eef260927c Version: $LATEST\n2022-04-05T23:38:01.600Z\t63555b90-79de-4937-bd26-f0eef260927c\tERROR\tUncaught Exception \t{\"errorType\":\"TypeError\",\"errorMessage\":\"Cannot read property 'getPublicKey' of undefined\",\"stack\":[\"TypeError: Cannot read property 'getPublicKey' of undefined\",\" at /var/task/node_modules/@redwoodjs/api/dist/auth/decoders/auth0.js:57:29\",\" at cb (util.js:290:31)\",\" at __node_internal_ (util.js:266:10)\",\" at processTicksAndRejections (internal/process/task_queues.js:82:21)\"]}\nEND RequestId: 63555b90-79de-4937-bd26-f0eef260927c\nREPORT RequestId: 63555b90-79de-4937-bd26-f0eef260927c\tDuration: 38501.47 ms\tBilled Duration: 38502 ms\tMemory Size: 1024 MB\tMax Memory Used: 355 MB\t\nUnknown application error occurred\n\n",
"parsedLambdaMessage": {
"lines": {
"data": {
"errorMessage": "Cannot read property 'getPublicKey' of undefined",
"errorType": "TypeError",
"stack": [
"TypeError: Cannot read property 'getPublicKey' of undefined",
" at /var/task/node_modules/@redwoodjs/api/dist/auth/decoders/auth0.js:57:29",
" at cb (util.js:290:31)",
" at __node_internal_ (util.js:266:10)",
" at processTicksAndRejections (internal/process/task_queues.js:82:21)"
]
},
"level": "error",
"message": "Uncaught Exception \t",
"timestamp": "2022-04-05T23:38:01.600Z"
},
"parse_status": "full",
"report": {
"billed_duration_ms": 38502,
"duration_ms": 38501,
"max_memory_used_mb": 355,
"memory_size_mb": 1024
},
"request_id": "63555b90-79de-4937-bd26-f0eef260927c"
},
"path": "api/graphql",
"projectId": "QmUh5xiTAcH85Ldy3DXWSF7wtwTwhfUtaWKEJcDgGwi2DA",
"proxy": {
"clientIp": "1.145.197.83",
"host": "api.buildpass.com.au",
"method": "POST",
"path": "/api/graphql",
"region": "syd1",
"scheme": "https",
"statusCode": 500,
"timestamp": 1649201843105,
"userAgent": "BuildPass/1.0.63 CFNetwork/1329 Darwin/21.3.0"
},
"source": "lambda",
"statusCode": -1,
"timestamp": 1649201843107
}
Doing some more digging into this. There looks to be a change in how a JWT is validated. Before it even gets to the getCurrentUser stage it blows up internally. It looks like it does this on invalid JWT’s so either JWT is not for the application or potentially even just expired ones.
As a result, it tends to exit and actually kill the process. Locally this just kills the app and I believe deployed onto Vercel it must just kill the function. We’re seeing issues now where our DB pooling gets exhausted as a result of a burst of these failing queries.
The “burst” seems to happen due to the way we have the architecture of our application, with a single page calling the graphql server multiple times. So if a user has a bad JWT and calls our server it floods it with errors.
Unfortunately, we cant seem to guard against this as it’s happening in the internals before getCurrentUser is called.
I’m going to try to deploy a brand new standalone RW application and hook it up to a new auth0 application to replicate.
I’ve been able to replicate this issue on a brand new install of Redwood, version v1.0.0.
Steps to reproduce:
requireAuth directiveThis should now cause the error and actually causes the API to crash/exit requiring a manual reboot. The console then shows:
api | TypeError: Cannot read property 'getPublicKey' of undefined
api | at /Users/aaronvanston/dev/buildpass/rw-auth0-test/node_modules/@redwoodjs/api/dist/auth/decoders/auth0.js:57:29
api | at __node_internal_ (node:util:279:10)
api | at processTicksAndRejections (node:internal/process/task_queues:83:21)
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request localhost:8910/graphql to http://[::1]:8911/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)
Note: An easy way to hit the API and cause this error, is locally going to http://localhost:8911/graphql then hitting the authed service, making sure to include the headers:
{
"auth-provider": "auth0",
"authorization": "Bearer eyJhbGciOiJSUzI...."
}
My code is public here: GitHub - aaronvanston/rw-auth0-test
This unfortunately is affecting us pretty bad with users hitting this error with invalid tokens then causing our API to get stuck and in a funny state causing issues connecting to the DB.
And @twodotsmax I have written up an issue here: Auth: Auth0 getPublicKey is undefined / TypeError: Cannot read property 'getPublicKey' of undefined · Issue #5079 · redwoodjs/redwood · GitHub
With a proposed solution that I’ll have to test out. Let me know if you think that solution might work in the issue — thanks!