https://supertokens.com/
Join Discord
Anyone get errors with token refreshes?
# support-questions-legacy
e
Anyone get errors with token refreshes?
My backend will occasionally return "{"message":"try refresh token"}"
despite i already refreshing the token and/or i just recently signed in.. Sometimes I'll re-hit the endpoint and it'll just randomly start working
n
Hey @Erick Can you elaborate on this? Are you seeing failures when trying to refresh? You will see 
try refresh token
errors if the access token has expired and you try to call an API that requires sessions (If you are using our frontend SDK, the SDK will try to refresh the session if the backend returns this error so you should not have to manually do it)
e
I was getting 401's on refresh, not sure why. I'm looking into it.
n
Yep, if you can give me more info (what sdks are you using, platform, whether you can reliably re-create the issue etc) I can help better
e
This might be two different issues, but the first one I'm noticing is that on my postman collections, I will sign in, (and store the cookies) then hit an API endpoint, and it will say
Copy code
"{"message":"try refresh token"}"
The backend is Go,
Copy code
github.com/supertokens/supertokens-golang v0.12.0
n
Our docs have a section for how to test with postman
You could try to see if youve missed anything there
e
Yeah, I followed that one
The only part I didn't follow is the anti-csrf, because we use cookies i believe
The weird part is.. eventually the API will work if i hit it multiple times on postman
This is using super tokens v5 saas
n
Hmm can I see the backend config you pass when initialising SuperTokens?
e
the recipe?
Copy code
session.Init(&sessmodels.TypeInput{
                GetTokenTransferMethod: func(req *http.Request, forCreateNewSession bool, userContext supertokens.UserContext) sessmodels.TokenTransferMethod {
                    return sessmodels.CookieTransferMethod
                },
                ErrorHandlers: &sessmodels.ErrorHandlers{
                    OnUnauthorised: func(message string, req *http.Request, res http.ResponseWriter) error {
                        res.WriteHeader(401)
                        res.Header().Add("Content-Type", "application/json")
                        res.Write(unauthorizedMessage)
                        return nil
                    },
                },
            }),
        },
n
That seems right, and you see the Set cookie header in the sign in response as well?
e
Yep, set-cookie is all there. both stAccess and refresh tokens are there
n
Do you set the cookie header manually when sending API calls to the protected API?
e
For postman, no. Postman automatically adds them when it receives it from response
n
Yep just making sure. Do you have SuperTokens core running locally?
e
No, I use the SaaS product which is on V5 I believe
n
Ok, everything is configured correctly then. Do you face issues with only Postman or do you face them in your app as well?
e
Here is my sign in request (first screenshot), and here is the response
Copy code
{
  "status": "OK",
  "user": {
    "id": "redacted",
    "email": "redacted",
    "timejoined": 1684100495661
  }
}
Second screenshot is the returned headers, which include the Set-Cookie
After I sign in, and hit an API endpoint, I immediately see
Copy code
{
  "message": "try refresh token"
}
, despite the access and refresh tokens being in the cookies
But if I wait like 3-5 seconds, it will work..
n
Alright let me see if I can recreate this issue on my end, give me a minute
e
Semes like a noticeable delay when after logging in, you will get try refresh token error. I'm able to replicate this consistently I'll report back what i am seeing in the app using the react library shortly. Thank you so much for the assistance. Happy to share more info
n
Yep, using it with a React app would be useful to know fi the delay is because of some internal Postman thing. If you like you can use 
npx create-supertokens-app@latest
to quickly set up a react app and then point it to your server
(It also sets up a basic backend for you so if that setup works you can compare)
e
Assuming it's not, it becomes a deeper problem for us because we use AuthSession HoC, which I believe will redirect back to login page if it fails to get a session 😐
And that's what we're observing rn, i'll get more info to you shortly
n
Right yeah let us know, in the meantime ill let you know if I can find a resolution for this
So I tried it and for me I would never have a delay. I sign in and immediately call a protected API and it works fine (this is on Postman).
e
Hmmmmm
Are you using the SaaS offering?
n
Hmm, im not. Let me try spinning a saas instance and trying
e
I am noticing a delay of 10-20 seconds before my token is valid
n
What region are you using? (trying to mimic it as close as possible)
e
Good point
us-east-1, dev environment
n
Alright, give me a minute
e
Are you using cookie based auth?*
n
Using the same config as yours
So cookies
e
This probably is irrelevant, but also go 1.20? As far as i know, the backend just pretty much proxies it over to a supertokens instance, so it shouldn't matter right?
n
It shouldnt matter
So even with a Saas instance im not seeing any delay
Is your go server running locally?
e
That is correct
I can try the production version too
n
No im running locally as well
e
GIN?
n
http, I can try gin too though
e
Thank you for your patience. This one is biazarre
github.com/gin-contrib/cors v1.4.0 github.com/gin-gonic/gin v1.9.0
n
Copy code
github.com/gin-contrib/cors v1.3.1
github.com/gin-gonic/gin v1.7.4
Works just fine for me
I see no delays with a production instance
Same region and same config
Not entirely sure what the error is here, you could try using a bare bones backend app (just the default config and no customisations) and see if the issue still persists
e
Can you try my version(s) as a last final sanity check?
n
Sure
e
There's only one super tokens core 5.0.0 atm right? no patch/minor versions
n
Yep 5.0.0 is the latest
e
gin.Default() as well?
Interesting! I don't see it in production* environment.
Wonder if my instance is just bugged 😐
sorry, typo.
n
Right well ill just test it all for sanity's sake anyway
e
Yeah, I can reliably call sign in and an API endpoint in production, but not developemnt instance
concerning
maybe i should try "clear data" in dev?
n
Well session verification does not rely on the core for sessions that just got created, so your core instance shouldnt really matter
But you could try asking the team to delete your app and then you can recreate it
Have you modified the database for your instance in any way?
Also yes clear data should reset your database to its original state (removing any modifications you may have made)
You can try that too
Also just an update, using the same versions as yours with 
gin.Default
and go 1.20 I still dont see a delay :p
e
Yeah, but the core generates the session right?
Wonder if the time or something is off on my development instance. Trying to delete now
I'm happy to share the development environment as a final sanity check lol
Ah, clearing the database did not work (though it did delete my users). Very very odd it does not happen on production instance. There is nothing different between prod and development at the moment except the core connection and api key.
I just hope it doesn't happen in production later on.
n
Hmm, like I said you could try deleting the app entirely and recreating it
e
How can i delete the app in SaaS??
n
Email us at team@supertokens.com with the email you registered with and the team will delete it for you
e
Does WEBSITE_BASE_PATH on the backend have any impact on session generation
n
It will be used to set the cookie domain, but it does not have any effect on session verification
e
is there a way to set multiple, i.e i have a development server
it would be nice to have localhost hooked up to it along with my development website url
n
We are currently working on adding support for this, at the moment it isnt possible
e
So my options is maybe switch to header auth, for development maybe?
n
I would check if deleting the app helps first
e
From what I understand, cookie was more secure option because storing this in localstorage or such is not safe
oh, sorry, this is unrelated issue lol
n
So you want to be able to use localhost along with your dev website url?
Or just one at a time
e
Yeah - localhost with dev
i have devs that would prefer to be able to log in from localhost without having to run supertokens
what do you mean by interception?
n
Oh right
e
I think with cookies, we are seeing issues with sesions, but i'm hoping with headers it'll work - lol
n
So you want one API server that is then used by the web devs running local and those using the dev server as well?
e
yeah, because they are frontend devs, don't really have much need to run a backend
its a bit overkill for them
n
Yeah using headers should work here although you are right in that it isnt as secure
That being said they can switch between headers and cookies on the frontend
e
Sweet, thank you for the re-confirmation
Yeah, i noticed it does it implicity, how does it know how to do that haha
n
You would have to remove the 
GetTokenTransferMethod
bit from the server for this
e
SGTM, thank you! I still don't know what's up with my dev server - the session refresh delay is still apparent, but i'll send in a ticket to remove it EOD. Thank you, you guys rock.
n
The frontend sdk sends a header to indicate to the backend what to use (if GetTokenTransferMethod isnt provided it honors it, otherwise it uses whatever GetTokenTransferMethod returns)
You could have that function return cookies for your production API server
And then for dev you can return any (another option similar to the cookies option)
e
There's like 50000 topics on this when implementing your own auth. No real good guidance, I'm glad super tokens handles it all for me, one of the bigger reasons why I picked it. TY.
n
That way both local (using headers) and then dev (using cookies)
And itll all work fine
e
This makes sense, good idea
n
Thanks!
We usually respond faster in work timings (the next 6 hours or so) so I would recommend doing it sooner if you want to test after re-creating it as well
But yeah EOD works too
e
gotcha, will file one now
r
hey @Erick
We are talking on email as well, (team supertokens), and thought to msg you here as well in case it was easier for you.
e
hey @rp_st the +dlb one is the one I was testing on, you can ignore the other account.
I never had an issue before v5.0, this issue only popped up on 5.0, but i'm not sure if it's exactly the cause, as the production instance of 5.0 works just fine as well
r
yea.. that's the really strange thing. The code that runs in either are identitical
can you reliably reproduce it?
e
Yes, I can. Since I am going to nuke the development instance, you guys are free to connect to it to see as well
I was wondering if it can be something like the instance time is out of sync or something 🤔
r
right. There are no errors from our end whatsoever. So this is verrryy strange.
What are you doing in code to cause this?
just a regular sign in?
e
This is strictly through postman
r
right
can you tell me the API calls please?
e
Just a sign in, then hit an authenticated endpoint which calls verifySession
r
ok. Can i see the postman request?
the url, body, headers
e
yes, for sure, let me take a vid
r
thanks
e
Mind if I DM you my access tokens and whatnot?
r
sure. Please DM
For ref for others: the issue was system time was not in sync
158 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