yup.

awesome!

aight, thanks for the help!

hmm, doesn't this mean we have 2 ways to store additional data? one from session data and another through jwt payload? is one preferred over the other?

Depends on the use case. You can read more about it here: https://supertokens.io/docs/session/common-customizations/sessions/new-session#storing-session-information

was thinking of how would the backend know who the user is as what we just discussed only validates the session xD

I guess I'll just store the userId on the session data then

can't trust the user's input, else they could just throw someone else's user id

Yup. U can

I mean u can store the userId in the session data

aight, we'll do that, thanks again!

@User since you want to change the password reset token's lifetime, until we make that configurable, you can fork the supertokens-core repo and change this value: https://github.com/supertokens/supertokens-core/blob/master/src/main/java/io/supertokens/emailpassword/EmailPassword.java#L45 Then build it by following: https://github.com/supertokens/supertokens-core/wiki/Building-from-source

Ok thanks, how we do it at the moment actually is with a sql trigger function on insert to the emailpassword_pswd_reset_tokens table. That enables us to have different validity periods for tokens before and after first login.

Ahh okay! That works too!

Hey guys, I've been playing around with the supertokens apis for the past few days and I have a few quick questions for you... 1) I've noticed that when I call init() on the 'supertokens-website' import, that if my api is slow to respond on the

/refresh

requests, the browser will continue to call the endpoint in an infinite loop until it receives a response. Is this behavior configurable at all? I would think that successive requests to

/refresh

should at least wait for the first to resolve, no? 2) In looking at the code, I've also noticed that the default behavior for the 'supertokens-website' SDK is to override the native fetch method on the window object so you can automatically have auth headers/refresh functionality baked into every request to the configured api domain. While I can understand why you went that route, I think it's a generally unfavorable precedent to set, and I don't like the idea of foreign javascript rewriting native methods on the window (particularly something as sensitive as fetch)... Since you already offer axios interceptors, is there a way to disable the native fetch overwrite behavior if I don't want to opt in?

hey @User , 1) That shouldn't be happening.. is there a way I can see your frontend code to help debug this? 2) Yes you can disable fetch interceptor like this:

supertokens.init({
    apiDomain: "...",
    override: {
        functions: (oI) => {
            return {
                ...oI,
                addFetchInterceptorsAndReturnModifiedFetch: (originalFetch, config) => {
                    return originalFetch;
                }
            }
        }
    },
});

note that if you disable the fetch interception, then methods such as sign out or getJWTPayload may stop working.. as those use fetch. So you will also have to override those functions to use axios instead.

These are all the functions you can override: https://supertokens.io/docs/website/usage/override/functions and their originalImplementation can be found here: https://github.com/supertokens/supertokens-website/blob/master/lib/ts/recipeImplementation.ts

@User thanks for the quick response! Yeah, let me try to isolate a little of the code for #1 to post here in a more readable fashion. For #2, ok cool, that sounds like a reasonable tradeoff for me, thanks for the insight!

@rp Ok, so for #1, what was actually happening was that the "apiBasePath" was misconfigured, so the request to

/refresh

was getting back a

200

from my server, but the response payload/headers obviously didn't have any tokens or useful auth information included. This is what was causing the infinite loop, and I can repro it pretty easily just by configuring my server to

res.status(200).send('ok')

on the endpoint

I guess in this case, the refresh behavior should perhaps throw an error if it doesn't get back the correct response?

It could.. you can create an issue about this on the repo, and we will impl it soon enough. Else you could issue a PR yourself 🙂

cool, I can put together an issue for it 👍

I ran into another issue in testing that I'm wondering about. I'm noticing that after upgrading to NextJS 11, I'm no longer seeing the signup/signin interface at the

/auth

route. What ends up happening is that for some reason, when I browse to

/auth

, I get redirected to the homepage. My configuration is the same as what's in the supertokens documentation online. Out of curiosity, is NextJS11 a known incompatibility? Nevermind, got this working by upgrading to latest version of

supertokens-auth-react

Hey again, back with another question... When using the

supertokens-website

package with fetch interceptors active, if I make a request against an express backend that's configured with

supertokens-node

using the

Session

recipe and both the

Session.verifySession({ sessionRequired: false })

and

supertokens.errorHandler()

middleware(s) for a given route, I (when applicable) get back a

401

from the server with a message "try refresh token". At this point however, nothing happens in the front-end. Should the fetch interceptor be auto-trying to refresh the token here or is this something I need to manually handle?

Hello! Quick question about the refresh token theft detection: does supertokens only store one parent refresh token? If so, what happens if an attacker refreshes the token let’s say, 3 times while the user is idle? Then the user comes back online to refresh their token? By storing only the last one used, wouldn’t we be unable to detect this?

> Should the fetch interceptor be auto-trying to refresh the token here or is this something I need to manually handle? @User This should be happening. If you are using

axios

, then make sure that you have added the interceptor to it.

Hmm okay, for this particular setup, I'm just trying to get things working with fetch

@User > By storing only the last one used, wouldn’t we be unable to detect this? In your scenario, the user would be using a refresh token whose parent, or itself would be in the db, however, the associated session handle would still be in the db. This would be enough of an indication of token theft and it would give you that error.