can you please share with me the app you created and tested it? so I can see if I can catch something I am missing in my app?
okay, please keep me updated
I just copied your auth setup from the screenshot you shared so there isn't anything you are missing in your set up.
My hunch is that the issue is on the supertokens side of things with how it is handling the auth tokens that are in the cookies of the request.
Could you try updating their "test login url" to use supertoken's /example endpoint, which seems designed to test auth sessions.
Also could you enable the refresh auth trigger again and set to time-based expiry, and set equal to whatever their access_token_validity config value is.
If you could share a screen recording of this that would be very useful! 
Hi @Jack_T
Re 1) ok, nice that my setup seems good.
Re 2) Supertokens requires (sAccessToken, sRefreshToken) as cookies to refresh the session with new tokens ofc, our current issue is that Retool isn’t triggering the Refresh Auth workflow when the API responds with 403/401 and even when we set timer to refresh it, it doesn’t get trigger too
Re 3) Supertokens don’t have an endpoint that we can use in ‘test login url‘ and the URL I set is doing it’s job as expected
Re 4) I already did and currently this is what I am doing
FYI:
- I added vars as duplicate submit for cookies to make sure they are there in every request, and still the same issue.
- I added a manual refresh and if the token expires and we refresh manually it removes the tokens (access, refresh) from the browser cookies!!!
Hi @CoderNadir,
Thank you for the details.
We can't seem to figure out why the refresh is not being triggered.
Are you able to provision another user(us at Retool) on your Supertokens account so that we can better try to reproduce this with Supertokens?
Would it be possible for you to come to our office hours so we can live debug the resource with you to see if we can either solve this or get a better handle on if a bug is preventing the expected flows to occur? If we can get a recording of your resource set up and show that the tokens are being wiped then we can show to our engineers to try to triage why this isn't working as expected 
Hi @Jack_T I am faaar away from you guys 
I cannot come to your office!
The office hours are on Zoom!
If you click the link it will have instructions on joining remotely
Oh sorry, Okay I registered a meeting tomorrow
1 Like
Hi @CoderNadir!
It was great to meet you in person. Just to summarize the next steps for us to work on, we believe the issue is that the refresh flow does run, but it is being sent from the Retool backend, and thus does not have access to the cookies that are stored in Retool's frontend, which would require some engineering work to see if we can remedy this by getting the cookies from frontend to backend.
If you could help us out by having your refresh flow run, while being pointed to a testing endpoint at Beeceptor, we can confirm the refresh flow is running, as well as that when it runs, the payload does not have the needed cookies.
Once we get that confirmation, my team and I can bring this to our engineers to get progress on a bug ticket or work around!
1 Like
Hi Jack, please check our DM 
For the community: I just shared with him the Payload received on Beeceptor when the Refresh auth workflow got triggered
Quick update for anyone else using custom auth with SuperTokens and cookies for refresh.
As per the docs here, you will need to add in a header of rid: session
1 Like
Also, it looks like we did find a bug on the Retool end 
The query will fail and the refresh flow will run, but the original failing query does not run again with the newly refreshed tokens as expected.
But when the original query is manually triggered, it will run and work.
A potential work around to this is to set the refresh flow to run after a certain amount of time(shorter than the time it takes the token to expire), that could be a work around. As the token will keep getting refreshed before it can expire.
1 Like