https://supertokens.com/ logo
Join Discord
Powered by
session refreshing
# support-questions
l
Do i have to retresh the session manually if i am using a custom ui with the supertokens web sdk?
r
you don't have to. Our web-js SDK should do it for you as long as you have correctly configured the apiDomain
l
@rp The api domain is correct (now). But i cannot see any refresh requests
Also, if a use header as tokenTransferMethod, the headers are not included in the request.
r
this means the api domain is not correctly configured.
what API are you quering?
And what's the value of apiDomain that you have set?
l
Its a public ngrok domain. I double checked the values which i have set in backend and frontend end they are equal. both https.
its works with cookies.
r
whats the request and response headers from the sign in API when you set tokenTransferMethod to header?
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110819799728148520/Bildschirmfoto_2023-05-24_08-40-39.png▾

r
and the response headers?
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110820130209923174/Bildschirmfoto_2023-05-24_08-42-10.png▾

r
ok so this is working as expected. Now, when an API call is made, can you show me the request headers?
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110821224877133824/Bildschirmfoto_2023-05-24_08-46-40.png▾

r
can you send me a screenshot of the cookie store on the browser post login?
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110822085648986142/Bildschirmfoto_2023-05-24_08-50-01.png▾

r
can you open package-lock.json and tell me which version of the supertokens-website SDK you are using?
Also, could you open an issue about this on our github here: https://github.com/supertokens/supertokens-website/issues Explaining your setup (apiDomain + session.init configs)
(And also attach these screenshots please)
l
I am using supertokens-web-js 0.5.0
r
right. That uses supertokens-website internally
so can you open package-lock.json and tell us which version of supertokens-website is being used
l
16.0.0
r
ok can you update it to using 
16.0.10
(which is the latest version) and see if that fixes the issue?
tagging @porcellus here to help as well.
l
i upgraded to 16.0.10. Same result.
r
ok. I'll let @porcellus help you when he is online
oh right. I see the issue.
do you have some cors setting on the backend about access-control-expose-headers?
like in an api gateway or something?
l
i am using ngrok
could that cause the issue?
r
no. It's an issue with the cors config. Where you have set the value of 
id-refresh-token
on the backend for access-control-expose-headers?
l
Heres my cors config:
Copy code
python

api = CORSMiddleware(
    app=api,
    allow_origins=[
       ...
    ],
    allow_credentials=True,
    allow_methods=["GET", "PUT", "POST", "DELETE", "OPTIONS", "PATCH"],
    allow_headers=["Content-Type", 'org-profile-id'] + get_all_cors_headers(),
    expose_headers=['id-refresh-token', 'front-token'] + get_all_cors_headers()
)
r
right. So add 
st-access-token
and 
st-refresh-token
to expose_headers as well.
and then it should all start to work
l
Okay, now i can query my api. Thanks.
Should this also fix the refresh-issue?
r
yes
get_all_cors_headers
should return the proper list. So it should have worked.
can you print out the value of 
get_all_cors_headers()
?
l
['anti-csrf', 'authorization', 'fdi-version', 'rid', 'st-auth-mode']
r
which version of the python SDK version are you using?
l
0.14.0
r
ok thanks. It should be fine now
l
I still cannot see any refresh requests. How often does the refresh request run?
r
depends on the access token's lifetime
set the access token's lifetime to 2 mins on the core, and then relogin. Wait for 2 mins, and you will see it refresh
l
I edited the access token lifetime. still no refresh requests.
r
are you getting back 401 try refresh token error when calling the API?
l
There is a refresh request after reloading the page. But no periodic requests.
yes
r
can i see the request headers for that API call which gives back a 401?
and also the subsequent network calls
l
Copy code
:method: POST
:path: /user/
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
authorization: Bearer eyJraWQiOiJkLTE2ODQ2MDExNzIyMTQiLCJ0eXAiOiJKV1QiLCJ2ZXJzaW9uIjoiMyIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiI2YzRmOWMwYi1jNzQwLTQ1N2UtOWI5YS01MmNiZWRhYWEyYWUiLCJleHAiOjE2ODQ5MTUxMTIsImlhdCI6MTY4NDkxNDk5Miwic2Vzc2lvbkhhbmRsZSI6IjhkMTg1NjhhLTlmMmQtNDEzZC1hMmZiLTMyZDczNmFhNTQ5YSIsInJlZnJlc2hUb2tlbkhhc2gxIjoiYTY3YjI4YTYzM2FmNDgzZTVhNjA5OTc3N2RmMGEzY2Q3MDk0MjEzZGE1ZGFkNTZlZGEzOGVkMzBkODlkM2QwYiIsInBhcmVudFJlZnJlc2hUb2tlbkhhc2gxIjpudWxsLCJhbnRpQ3NyZlRva2VuIjpudWxsLCJpc3MiOiJodHRwczovL2FwaS1jb3Vyc2VtYW5hZ2VyLm5ncm9rLmRldi9hdXRoIiwic3QtZXYiOnsidiI6dHJ1ZSwidCI6MTY4NDkxNDgxMTg3N319.YutojwTKG6anyxeDSc3Wm1LGkM5gtCT87iuSI1AYeR5SRl-1_jj8in4pxmxFf5y6rP4jmulA0hpcm_9gurOLo-UD-VRytfrzjwIGBxfxYAaEbVtgySL1UwW3si3P_l_ucFb9cMbNIGmWRVxjCwrI6kDLNPw8P6tn9hzJbZ8dFc6gsrzXZsy7XCYr9xq9jwbYHMEouFiJCbu6hIMnMDOdgAKjyu5O-UETrrQpHhkxbZ3mMifrbfsKI-fIg0dt0WZA8LSQFVe3x6zwgnEQJ7KhS4OQLYpqtq3O-tPpRrpe4sS5R77U8kC4wqgIfFEiLQ1Zkkb-2SYeIy1Y8q3vDmFmdw
content-length: 422
content-type: application/json
org-profile-id: null
origin: https://dev-coursemanager.ngrok.dev
referer: https://dev-coursemanager.ngrok.dev/
rid: anti-csrf
sec-ch-ua: "Not:A-Brand";v="99", "Chromium";v="112"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
st-auth-mode: header
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36
Response
Copy code
access-control-allow-credentials: true
access-control-allow-origin: https://dev-coursemanager.ngrok.dev
access-control-expose-headers: id-refresh-token, front-token, st-access-token, st-refresh-token, authorization, rid, anti-csrf, fdi-version, st-auth-mode
content-length: 21
content-type: text/plain; charset=utf-8
date: Wed, 24 May 2023 07:58:39 GMT
ngrok-trace-id: 4c8a6860f38ee27f526619fb3c3a701e
server: uvicorn
vary: Origin
r
can i see the network tab screenshot?
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110840472093610034/Bildschirmfoto_2023-05-24_10-03-06.png▾

r
you aren;t getting a 401
you are getting a 400
please see your API.
l

https://cdn.discordapp.com/attachments/1110812370114191420/1110840850726006877/Bildschirmfoto_2023-05-24_10-04-34.png▾

r
are you using some sort of custom error hadling?
cause try refresh should send a 401. Not a 400
l
yes
Refreshing is working with my main frontend.
r
im not sure why your api is sending a 400 instead of a 401
can i see your session.init on the backend?
l
Copy code
def init_supertokens():
    init(
        app_info=InputAppInfo(
            app_name="CM",
            api_domain=API_HOST,
            website_domain=FRONTEND_MANAGER_HOST,
            api_base_path="/auth",
            website_base_path="/auth",

        ),
        supertokens_config=SupertokensConfig(
            connection_uri=SUPERTOKENS_CONNECTION_URI,
            api_key=SUPERTOKENS_API_KEY
        ),
        framework='fastapi',
        recipe_list=[
            session.init(
                cookie_secure=True,
            ),
            emailverification.init(
                mode='REQUIRED',
                email_delivery=EmailDeliveryConfig(
                    override=email_delivery_override
                )
            ),
            thirdpartyemailpassword.init(
                sign_up_feature=thirdpartyemailpassword.InputSignUpFeature(
                    form_fields=[InputFormField(id='name')]
                ),
                providers=[

                ],
                email_delivery=EmailDeliveryConfig(
                    override=email_delivery_override
                ),
                override=thirdpartyemailpassword.InputOverrideConfig(
                    apis=override_thirdparty_email_password_apis
                )
            )
        ],
        mode='wsgi'
    )
r
do u have some custom error handler anywhere?
also, how are you protecting that api route?
l
I have a custom auth backend
a starlett auth middleware.
r
i don't quite know what effect that will have.
you may wanna investigate why it's returning a 400 instead of a 401.
l
Because i am returning an Exception instead of an auth error. I will fix this. But like i sad before: The refreshing is working on my other frontend. It uses the same backend.
r
once you fix this, let's see what happens. If the issue is still there, we will investigate.
l
Now refresh is running after the request has failed with status 401
r
yup.
2 Views
PreviousNext
Powered by