Supertokens issues/enhancements

Get Help and Help Others
1

Hello,

In Supertokens, the redirectTo mechanism does not work.

login/signup useAuth call superTokens.redirectToAuth and should use the argument queryParams={redirectToPath:“XXX”} instead of redirectBack: true, where XXX is the redirectTo queryParam of redwood
Here is the code I am using on top of redwood native implementation to enable this feature if it can help

const superTokensClient = {
  sessionRecipe: Session,
  redirectToAuth: function (options: {
    show?: 'signin' | 'signup'
    history?: unknown
    queryParams?: object
    redirectBack: boolean
  }): Promise<void> {
    const url = new URL(window.location.href)
    const redirectTo = url.searchParams.get('redirectTo')
    if (!redirectTo) {
      return SuperTokens.redirectToAuth(options)
    }

    const newQueryParams = {
      redirectToPath: redirectTo,
      ...options.queryParams,
    }
    const newOptions = {
      show: options.show,
      history: options.history,
      queryParams: newQueryParams,
      redirectBack: false,
    }
    return SuperTokens.redirectToAuth(newOptions)
  },
}

Also I noticed that the jwks token endpoint on supertokens is continuously hit with no caching. The jwks-rsa native client caching is not working because the jwksClient object is scoped to the authDecoder function in packages/auth-providers/supertokens/api/src/decoder.ts
Maybe worth defining it in a global/singleton ?

1 Like
2

Hey @mat :wave:

This sounds like a bug in our supertokens auth implementation if we’re doing things like passing the wrong parameters around. Do you think you could open up a github issue for it? We have an issue template which should help you provide enough information but the most helpful thing would be a nice clear list of steps to reproduce this behaviour. Even better would be a link to a repository that shows this behaviour.

Once we have an issue I can then make sure it’s on our radar to work towards a fix. I would be great if you were willing to help contribute a PR to help fix this? It’d be nice if we could upstream some of that fix you mention here but no pressure at all.

Your second point around the potentially inefficiency of the token endpoint also sounds reasonable. I don’t have any concrete response to your idea of a singleton/global. I do recall that we have updated our Clerk implementation in the past and remember concerns about rate limits for tokens being mentioned. Perhaps there is some prior art in this area we can work from. I’ll loop in @dom who I think worked with Clerk on it and see if he has any thoughts but I know he’s quite busy so might not be able to look into things in crazy detail just yet.