I’m using the azureActiveDirectory auth provider in my Redwood app. An hour (3600 seconds) after starting the app locally, the JWT expires and I get an error in my terminal:
graphql-server Error building context. Error: Exception in getAuthenticationContext: jwt expired
Reloading the page doesn’t help immediately, but it seems like after 5 minutes or so the token eventually refreshes.
As I understand it, getToken() should automatically refresh the token with MSAL’s acquireTokenSilent.
I assume GraphQL api calls from Cells call getToken(), since an authorization header is included in those requests, so I don’t understand why the token would expire.
Just wanted to +1 this as we’re experiencing the same thing.
It also appears that jwt expired does not trigger requireAuth(), so it is difficult to test for an AuthenticationError and handle it (RedwoodJS masks the error as the generic “Something went wrong”).
Were you able to figure this out? Trying to decide if this is an MSAL issue or a Redwood issue or something with our application.
We are seeing the same behavior. Only in local development.
Most of the time it disappears on the second try. One workaround if it does not go away was changing the time of the local machine to an hour in the future and back.
@Tobbe Unfortunately not. I had the same issue a couple of times when I did local development, and a handful of reports from end-users, but could not properly pin-point why and how this happened. I guess there is something in the logic that is missing.
Could you be able to have a look on it, in preparation for v4?
Hi, i just wanted to know if this issue has been fixed ?
Because i’m currently using Redwoodjs 5.0.5 and i have the same error :
10:45:54 🚨 graphql-server Error building context. Error: Exception in getAuthenticationContext: jwt expired
10:45:54 🚨 Exception in getAuthenticationContext: jwt expired
api |
api | 🚨 Error Info
api |
api | {}
api |
api | 🥞 Error Stack
api |
api | Error: Exception in getAuthenticationContext: jwt expired
api | at onContextBuilding (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@redwoodjs/graphql-server/dist/plugins/useRedwoodAuthContext.js:32:15)
api | at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
api | at async Object.contextFactory (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@envelop/core/cjs/orchestrator.js:198:45)
api | at async processRequest (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/graphql-yoga/cjs/process-request.js:46:26)
api | at async YogaServer.getResultForParams (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/graphql-yoga/cjs/server.js:331:26)
api | at async YogaServer.handle (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/graphql-yoga/cjs/server.js:78:29)
api | at async handlerWithErrorHandling (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@whatwg-node/server/cjs/plugins/useErrorHandling.js:33:38)
api | at async handleRequest (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@whatwg-node/server/cjs/createServerAdapter.js:73:24)
api | at async handlerFn (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@redwoodjs/graphql-server/dist/functions/graphql.js:182:24)
api | at async execFn (/home/nassim/Work/Lisaqua/lisaquapp/app/node_modules/@redwoodjs/graphql-server/dist/functions/graphql.js:237:16)
Sadly, no, it has not been fixed. As someone working on an app that uses Azure AD, it is incredibly frustrating to deal with this once an hour. The workaround of changing the local system time doesn’t seem to even work as well as it used to, either, so every time it happens my work grinds to a halt for several minutes.
My case is exactly as documented in the first post in this thread - after about an hour, I start getting the same jwt expired messages. It used to be as mentioned by @tilmannb in post #2 in this thread that changing the time and the setting it back would fix it. Now it just seems I have to wait five minutes as @ihusemann said in post #1.
As has been said in other posts, this does not seem to occur in our dev environment (which is a local Linux box in the office running Nginx/PM2), and it does not occur in our test or prod environments, which run on Azure. I get that it’s not a show-stopper as it only affects local dev, but it is definitely a regular annoyance.
Happy to provide any other debugging information/details that may help.
I still see the error from time to time. Sometimes I have the feeling it is a caching problem. It feels like the token is cached somewhere in the process. If I click on the element and start the same GraphQL query again it will work.
I will add a video if it happens again. Very hard to debug cause of the irregularity.
We also get this error on local dev on our Windows machines. It happens often if you leave the computer on overnight or yarn rw dev has been running for a long time. A restart of the machine usually helps.