https://supertokens.com/
Join Discord
Hi, when clicking on signout, or hitting any endpoint where we validate the session i get a inifinit...
# support-questions-legacy
e
Hi, when clicking on signout, or hitting any endpoint where we validate the session i get a inifinite loop of requests "try refresh token" cant figure out what's wrong
r
hey @EdwinN1337 which backedn SDK do you use? And which version?
and after the sign out is called, i assume the refresh API is called? What does that API return?
e
hey! v14
r
and does the call to the sign out API use the new access token?
e
how can I confirm that it uses the new access token?
Copy code
js
import { signOut } from 'supertokens-web-js/recipe/thirdpartyemailpassword'
import { logError } from '../../shared/utils/logError'

export const useSignout = () => async () => {
  try {
    await signOut()
  } catch (err) {
    logError(err)
  }
  window.location.reload()
}
this is our signout logic
it does work in prod tho, not locally so thats why im confused
r
this seems fine. However, does the new sign out API call post refreh use the new access token?
e
st-refresh-token=Cy8UHFvd1rl5Z3ZDo5/0NFp28FXJnGcOiksKIsKUxAVYJfJ53eV8gV70PPlQvBc5TFNqa6L3Zv9QidKr917Vvg/bwgdOFnClyjuZoh4nEFRlj4TzEEq1+irXgqwzMN9RMnqjE2z9CkcOhP8vjDUJ9TclTb8HbxLHEYdYm8hENjC6X6LLTp9edYX34zsRw8S5TWHE7LMyIE9mQfWtHMJNVsFnj/x4cw+vgoqJipVmejKegwV5JLqE6QSianZUG+oetU6ZEBPzzPDlXgrx2AQXDDnIIbv2GszIKPaPECLbiXu8P6hB3pAE3FU1hFIx8UN7Z9Gpft5qah2SCYyFGEqgr3AnGjbiO0i9cvwxEIGmYCX7t0YrJEmRqBq/pennScvIyvtHqv6PCBH9c9zr.e89d7057978187f301bc557becd72a26ab1425d39d47295a3b5b2a7691a433cf.V2; yeah, added to headers
it does use the new token from what i see
r
ok. Can you enable backend debug logs and show the outpyt of the sign out API?
e
Copy code
js
        exposeAccessTokenToFrontendInCookieBasedAuth: true,
        getTokenTransferMethod: () => 'any',
we use this in our backendConfig
message: "getInfoFromAccessToken: Returning TRY_REFRESH_TOKEN because access token validation failed - The "listener" argument must be of type function. Received an instance of Object
r
"because access token validation failed - The "listener" argument must be of type function. Received an instance of Object" -> this is strange. Can you open an issue about this on our github?
e
sure, will do.. my collegeau is back tommorow he said everything worked fine on his side
r
oh. this is just not working on your machine?
@sattvikc can help here.
e
nop, im on windows
99% sure our envs are the same tho
he's on mac
r
hmm. I see.
e
but cant compare, he's not here 😉 but it causes infinite loop locally so thats why i reached out
r
well, if you open an issue about this with more details, we can help asap.
e
will do when i compared our setup, so i got some more details
r
thanks.
e
u2
hey @rp_st we got this issue on production aswell, when we hit error and got redirected to the error.tsx from nextjs page, somehow the refresh function returns a 401 and causes a inifinite loop, trying to refresh it with the same message "try refresh token" (its also hitting a endpoint were we use) await superTokensNextWrapper(async next => verifySession()(req, res, next), req, res) will look into it monday, we got no time today but thought i give you a headsup 😉
r
Hmm okay. Well, we still can’t replicate it. If you tell us the prod url, maybe we can get more info by logging in and out ourselves.
e
Hey, finally got time to fix it. I've been clicking around in production, and there is something with the session. Just had this infinite loop on production again, hitting a serverless function which is using the nextwrapper for validation. When I open my incognito browse log on the same account but then incognito, it works. And when I refresh my non-incognito tab the infinite loop is gone...
hard to replicate
r
perhaps @porcellus can help out here.
e
Great thanks, got it on prod now so i could share my screen
trying to replicate locally again
@rp_st i kept my screen open for 5 mins and suddenly it worked
more info: when the app is open for a while (logged in), and I hit hard refresh we get this infinite loop again and a white screen my guts says we are hitting the /knock endpoint where we use the supertokensnextwrapper, before a refresh happens?
@rp_st, some extra info you might see whats going on
r
which frontend and backend SDK versions are you using?
e
Copy code
js
    "supertokens-node": "14.1.2",
    "supertokens-web-js": "0.6.0",
r
and which core version? And are you usingo our managed service or self hosted?
e
managed service, v5
r
can you enable backend debug logs and show the output when you get a 401 from the API (and when you are stuck in this infinite refresh loop)?
e
yes, will do have to rebuild on prod
logged in again, guess I have to wait like 10/15mins when it expires
and hard refresh
r
yup
e
got it
message
r
"The "listener" argument must be of type function."
im not sure what this error means.
We shall wait for @porcellus to help here.
e
okey, for now I will extend the access token validity to a day ~
r
alright!
e
it seems like inactivity is causing the issue,
r
yea. I'm really not sure whats causingt this. But @porcellus will be able to help
e
thnx!
p
this seeems very strange - could you check what version of 
jose
you have installed?
oh and the 
node
version could be interesting as well.
e
Sorry im here, didnt see ur message
node 18.x
havent installed it directly? if this is what you mean
p
node 18 should be ok.
it's strange that you have 
jose@2.0.6
installed, but I guess that should be ok if the version we get is the right one
you can reproduce this locally right?
e
well, yea let me try again. It's basically happens when ur inactive > so i have to login and wait 10mins and then we get this issue
p
right
e
this behaviour started to happen when we upgraded our supertokens core btw
p
before trying to replicate it could you edit the 
supertokens-node/lib/build/recipe/session/accessToken.js
file in your 
node_modules
it's a weird way to debug, but it may be the quickest
if you could add a console.log before the 
logDebugMessage("getInfoFromAccessToken: Returning TRY_REFRESH_TOKEN because access token validation failed - "...
logging the error being caught
I mean the entire 
err
object (incl. the stacktrace most importantly)
it should be around line 215
e
will do! moment
p
thanks 🙂
e
console.log(err) i assume?:D
p
yup
e
ok, i have to wait 10 mins i guess and then hard refresh the page to reproduce
hmm weird, can't replicate it locally -.-
p
weird. is the prod also running on node18?
e
ye it is
it happens randomly,
now i get a 401, but all good
have to go for a hour now, i'll try to reproduce later today so I can log it
p
thanks.
e
hey i got it locally
TypeError [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type function. Received an instance of Object
@porcellus
p
hi
that's great, but was there no stack trace?
e
no there was not
p
oh, but there is, right below the error. it seems to point to some package you are using: 
proxy-agent
(or specifically it's dependency: 
agent-base
). A quick google search shows that this patches over the built-in http(s?) in a way that is not compatible with 
jose
.
e
seems like @sentry/node is using it
Copy code
js
"@sentry/node@7.54.0":
  version "7.54.0"
  resolved "https://registry.yarnpkg.com/@sentry/node/-/node-7.54.0.tgz#ebdc1f5d91e97bbfbbc70192bf2bf77433f5f55f"
  integrity sha512-k8P7WD6lra3JF3H/y9GO+twBV8qQilj3X3d8PpaVPBHHwOA9AfdBVF18qgrdlZKghKtgALapZzrQQVnTOm34rw==
  dependencies:
    "@sentry-internal/tracing" "7.54.0"
    "@sentry/core" "7.54.0"
    "@sentry/types" "7.54.0"
    "@sentry/utils" "7.54.0"
    cookie "^0.4.1"
    https-proxy-agent "^5.0.0"
    lru_map "^0.3.3"
    tslib "^1.9.3"
Copy code
js
      sentry: {
        excludeServerRoutes: [
          // Other routes you might want to exclude...
          /^\/api\/auth\//,
        ],
      },
im already excluding it from next.config, for all auth routes hmm
p
e
hmm, weird we got a recent version of sentry issues says its fixed
any idea how to get pass this issue, can't really figure it out to be honest
p
I'm not sure to be honest. Check what adds 
socks-proxy-agent
and proxy agent. maybe it is also added by something else in your deps? not sure.
e
ah, the weird part is we havent changed any dependencies lately. the only thing that has changed was updating supertokens core & versions
from what I see its sentry which is using this dependency (and cloudinary), both on v5 https-proxy-agent
r
Yea, we used to not use Jose before, but now we do cause it’s edge function compatible.
But it’s still strange. Cause earlier we used to use jsonwebtoken which depends on Jose as well. So if it worked with jsonwebtoken, maybe something is lacking with how we use Jose? @porcellus
e
ah right. we had issues with supertokens & sentry before, when updating sentry,
Copy code
js
      sentry: {
        excludeServerRoutes: [
          // Other routes you might want to exclude...
          /^\/api\/auth\//,
        ],
      },
so we opt-out from sentry on the auth server routes
https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/ i'lll add
Copy code
js
 autoInstrumentServerFunctions: false,
optout for the auto instrumentation, just to confirm that its sentry which is causing the issues
p
Jsonwebtoken was using a different subset of jose I think
The most confusing thing is that it only fails sometimes
e
blegh, this wasnt the solution turning sentry off 😦
well its when u have inactivity, then it fails, so after the expiration of the refreshtoken?
p
I see that that's how you reproduce it, but it fails when fetching the jwks, which is something we call during access token validation (and caching the results for 1 min).
e
right, what version did you start using jose / supprting edge. We might have to downgrade then, since its affecting our users in prod ;p. can't really turn sentry off
p
I think it was 
14.1.3
e
Also to point, when my colleagues gets this issue. They can't use our app, not even by opening a new browser of incognito
Does that make sense?
p
yeah
e
Oki :p
p
from that point on fetching the jwks fail, which means no access token validation can happen.
e
Right, we are using 14.1.2, btw
Is there anything that can be fixed from your side? Trying to understand where to go from here 😉 little lost hehe
p
hmm, I'll double check when it was replaced. there was one chunk of edge function support we added in 14.1.3 for sure.
e
thanks!
p
right, this was added at 14.0.0
well, the issue seems to lie outside of our SDK, not sure what we can do. I'll do a bit more investigation.
is there some code/repo/repro I could check out?
e
downgrading to 14 is not a option, or we have to fix the other issues we had 😦
hmm, yea we will try to make a reproduction
p
that'd be awesome.
e
quick check, if we catch this 401, try refresh token response is there something we can do to let is pass by calling some method manually? as a workaround?
hmm, maybe i found a way which solved it for now (atleast i was 20mins of inactive and all worked)
Copy code
js
  integrations: [
    // new Sentry.Replay({
    //   // Additional Replay configuration goes in here, for example:
    //   maskAllText: true,
    //   blockAllMedia: true,
    // }),
  ],
we turned off Sentry.replay feature (which is not a bigdeal for us)
i was googling abit, saw they were adding alot to the request
fingers crossed it will keep working, but for now it seems solved
p
> quick check, if we catch this 401, try refresh token response is there something we can do to let is pass by calling some method manually? as a workaround? Not really. I think after the jwks calls break, there is no real recovery. The global request method is already patched in a non-compatible way by then, meaning it will not start working later if something doesn't restore the original global.
> we turned off Sentry.replay feature (which is not a bigdeal for us) hopefully this works, but I might look into this a bit more later because this is a very strange thing.
e
ah, no this sentry replay wasnt the issue
it's like everyone has the issue on the same time
just got a message of 2 collegeaus "can't enter the dashboard", so i refreshed and i get this infinite loop error again
😭
r
can confirm the above, it works at a certain time but then for multiple people at the same time it stops working (I am a colleague by the way of Edwin)
e
yeah, no 1 can login at the same time. its not user related
r
Can you make a demo app that reproduces this issue? Ideally on top of our demo apps?
It will help us solve this quicker
p
this is not user related. my best theory is still a global function being patched in the server in a non-standard way. if it breaks for one request/user it breaks for all others (that are handled by the same process).
e
rob is gonna reproduce copying our "stack", so nextjs, sentry, hasura, all on same version... hope this reproduces it
and hope we're not missing a depedency which breaks it hehe
another point to make: we have 2 apps connecting to the same core, 1 app, it works, other app doesnt
also this is random obvious 😉
our [[...path.ts]]
Copy code
js
export default async function superTokens(req: NextApiRequest & Request, res: NextApiResponse & Response) {
  await authCors(req, res)
  await superTokensNextWrapper(
    async next => {
      // This is needed for production deployments with Vercel
      res.setHeader('Cache-Control', 'no-cache, no-store, max-age=0, must-revalidate')
      await middleware()(req, res, next)
    },
    req,
    res,
  )
  if (!res.writableEnded) {
    res.status(404).send('Not found')
  }
}
using this setHeader the /knock endpoint doesnt
Copy code
js
supertokens.init(backendConfig())

export default async function knock(req: SessionRequest, res: NextApiResponse & Response) {
  // we first verify the session
  await authCors(req, res)

  await superTokensNextWrapper(async next => verifySession()(req, res, next), req, res)
  if (!req.session) {
    return res.status(401).json({ message: 'Unauthorized' })
  }
could this be related?
r
i don't think so.
r
When I run 
yarn why jose
in our project I get:
Copy code
=> Found "jwks-rsa#jose@2.0.6"
info This module exists because "_project_#dashboard-web#supertokens-node#jwks-rsa" depends on it.
It is weird because also in my reproduction you can see the jose with version 
2.0.6
and it comes from Supertokens - https://github.com/RobSchilderr/capacitor-supertokens-nextjs-turborepo/blob/main/yarn.lock in this repo, when I run 
yarn why jose
I get:
Copy code
=> Found "jwks-rsa#jose@2.0.6"
info This module exists because "_project_#jwks-rsa" depends on i
p
right. so you have 
supertokens-node@13.6.0
in there as well as 
supertokens-node@14.1.2
r
Ah let me update that, in our other project we do only have 
supertokens-node@14.1.2
though, let me see
I just removed the redundant 
supertokens-node@13.6.0
and pushed it, it seems that the 
jose@2.0.6
is still in my `yarn.lock`:
Copy code
=> Found "jwks-rsa#jose@2.0.6"
info This module exists because "_project_#next-web#supertokens-node#jwks-rsa" depends on it.
p
the 
jwks-rsa
dependency was only removed in 
14.1.3
r
meaning updating to 
14.1.3
could fix the issue?
p
unlikely unless your package manager is doing something very weird (which could always be the case), but it'd simplify things for sure.
and it's worth a try since you don't need to migrate anything, it's only a patch level change
r
trying now, letting you know soon
e
upgrading didnt fix the issue, but did remove the old jose
we're turning off sentry completely to check if its related to sentry
its not sentry related 😦
r
Were you able to reproduce the issue in a demo app?
p
Is the error stack still pointing to agent-base?
And/or is it still installed?
e
Rob is still trying to create a demo app 😉 some parts like hasura should be added we think
Copy code
js
shop-web:dev: 2023-08-15T13:54:15.064Z com.supertokens {t: "2023-08-15T13:54:15.064Z", message: "parseJWTWithoutSignatureVerification: version from header: 3", file: "C:\Projects\Lokalist\monorepo\node_modules\supertokens-node\lib\build\recipe\session\jwt.js:54:22" sdkVer: "14.1.3"} 
shop-web:dev: Edwin TypeError [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type function. Received an instance of Object        
shop-web:dev:     at checkListener (node:events:266:3)
shop-web:dev: 2023-08-15T13:54:15.064Z com.supertokens {t: "2023-08-15T13:54:15.064Z", message: "getSession: got access token from header", file: "C:\Projects\Lokalist\monorepo\node_modules\supertokens-node\lib\build\recipe\session\sessionRequestFunctions.js:84:30" sdkVer: "14.1.3"} 
    at ClientRequest.once (node:events:647:3)
    at new ClientRequest (node:_http_client:245:10)     
    at Object.request (node:https:360:10)
     at Object.<anonymous> (C:\Projects\Lokalist\monorepo\node_modules\proxy-agent\node_modules\agent-base\patch-core.js:25:22)  
     at Object.request (C:\Projects\Lokalist\monorepo\node_modules\socks-proxy-agent\node_modules\agent-base\patch-core.js:23:20)shop-web:dev:     at https.get (C:\Projects\Lokalist\monorepo\node_modules\socks-proxy-agent\node_modules\agent-base\patch-core.js:34:21)     
    at fetchJwks (C:\Projects\Lokalist\monorepo\node_modules\jose\dist\node\cjs\runtime\fetch_jwks.js:21:17)
 2023-08-15T13:54:15.064Z com.supertokens {t: "2023-08-15T13:54:15.064Z", message: "getSession: using header transfer method", file: "C:\Projects\Lokalist\monorepo\node_modules\supertokens-node\lib\build\recipe\session\sessionRequestFunctions.js:104:22" sdkVer: "14.1.3"}shop-web:dev: 2023-08-15T13:54:15.064Z com.supertokens {t: "2023-08-15T13:54:15.064Z", message: "getSession: Value of doAntiCsrfCheck is: false", file: "C:\Projects\Lokalist\monorepo\node_modules\supertokens-node\lib\build\recipe\session\sessionRequestFunctions.js:144:18" sdkVer: "14.1.3"}
still pointing to agent-base 😭
Copy code
js
=> Found "cloudinary#proxy-agent@5.0.0"
info This module exists because "_project_#business-web#cloudinary" depends on it.
info Disk size without dependencies: "52KB"
info Disk size with unique dependencies: "1.36MB"
info Disk size with transitive dependencies: "6.46MB"
info Number of shared dependencies: 54
Done in 0.72s.
its cloudinary who uses the proxy-agent,
not even sentry
p
Right, so that could be the issue.
e
we got 2 versions of proxy-agent 3.1.1 and 5.0.0 the 3.1.1 is related to mailgun-js, but mailing is only happening on the server so could this affect anything on the client?
Copy code
js
    "mailgun-js": "^0.22.0",
super old depedency, we could upgrade this one but can this be related?
p
not sure what you mean by affect anything on the client.
e
well, what i mean by that is could it be that the mailgun-js proxy-agent of vs 3.1.1 is somehow used?
p
I'm not sure how mailgun-js works/what it does.
e
ah its our email sdk
p
it does seem plausible that the proxy-agent patch would be applied whenever the mailing lib is used, which would break future verifySession calls
e
ah, we do use the sdk in our backendConfig
let us update mailgun! try this
p
you could also check if this is the culprit by: 1. create a session 2. triggering mailgun somehow 3. wait 1 min (so the cache is invalidated) 4. make a call that tries to verify the session.
but maybe just updating is quicker
e
right, will do !
🙂 its removing the proxy-agent
r
for now it looks like it solved our issue! will keep you updated
e
all works still, so i guess it was mailgun old package which was causing this issue
proxy-agent v3
r
I’m glad it got resolved. Thanks @porcellus. Coding can be fun 🙃
e
Yeah it can be 😛 thanks for all the effort again!
39 Views
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by