Coincidentally, it also means that the debugger at jwt.io won't work with the unhashed secret. js, jwt auto-generates a signing key using futoinHkdf, which hashes the secret, meaning the secret on Apollo server no longer works. This is fine, as long as I use the same secret on the Next app server and the API server. I'm using the token I get from Next-Auth to authorize and authenticate users on a backend API server running Apollo Server on top of Express. I spent some hours looking at this in anger this weekend and I think I've cracked it or at least some part of it. The function is only about 30 lines long so it should be quick to track down the underlying cause. We actually no longer minify the transpiled JavaScript in NextAuth.js on publish, to make this sort of thing easier (as the saving in file size is minimal as the library is delivered compressed anyway), so it should be fairly straightforward to add some console.log lines to that file inside the getToken method and see exactly what is going on. You can do this either by editing node_modules/next-auth/dist/lib/jwt.js locally or copy and paste the code into your own project (the only thing you'd need to stub out are the logger lines and it's only referenced in the import and on two other lines) and debug the getToken function till whatever is causing the errors surfaces. I suspect the only way you are going to get to the bottom of this is to debug what's going on inside the library when running locally. This behaviour is expected (and happens) if a shared secret is not configured, but beyond cannot currently be replicated on Mac OS X, Linux, Windows or on x86 or ARM, or on Vercel, with Chrome, Firefox, Safari or Edge, using the example repo provided. I deployed the branch provided to and configured the instance it in Vercel (with GitHub as a new provider created specifically to test this site, as shown below) and that also works. I even tried using the same secret as in the screenshot above. I also installed this repo fresh with Yarn rather than NPM (as Yarn making different determinations for dependencies can sometimes cause problems in edge cases) and specifically with Chrome and Firefox (as per screenshot) works for me with no issues. I've tried specifically with Google as a provider, and again works okay from that branch for me. My version, cloned from last night and published on Vercel this morning, is here: That does not show up in the Network tab on my version of the example app. Indeed, I'm being forced to grant permission on successive attempts, but I'm still getting 304s.Īnother difference I noticed is that the official version has an entry for a script at I removed the application from my account at and added the authorizationURL: as suggested at. I inspected the Network tabs for both versions side-by-side and found that my version gets a 304 Not Modified status to the jwt file GET request and it uses the cached version. I cloned the example app from the Next-Auth repository and posted to my Vercel account, added my Google credentials and the NEXTAUTH_URL env variables ("mine") and then ran it side-by-side with the official Next-Auth online demo at ("official").
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |