https://supertokens.com/
Join Discord
hello! I am using thirdpartypasswordless + your managed service with react and fastapi. Everything...
# support-questions-legacy
a
hello! I am using thirdpartypasswordless + your managed service with react and fastapi. Everything was working locally, and I am trying now to deploy. After the user attempts to sign in (either passwordless or thirdparty) they are routed back to "/auth". for passwordless: User receives email in inbox, clicks link to ..../auth/verify?... , then gets routed back to /auth. for thirdparty: User clicks on their service, the service signs them in, then the user is routed back to /auth. In all these cases, the user is unable to access protected routes. I am using override_thirdpartypasswordless_apis() on the backend, but it all worked locally, so I'm not sure what the case may be. Any ideas?
r
hey @andrewbyrley have you correctly set the appInfo on the frontend and backend to match your production urls?
a
I'm pretty sure that's all right. both api_base_path and website_base_path are /auth
and the front end can talk to the backend on unprotected routes
within 
override_thirdpartypasswordless_apis
things generally seem to be working. when i check the supertokens dashboard, I can see the new users
...and the custom functions I call within override_thirdpary.... are running successfully, too.
r
so usually, the user being redirected to 
/auth
means that the frontend thinks that the session doesn't exist. This can happen if the session tokens aren't added to the frontend correctly during sign in, which usually happens if the appInfo stuff is not corectly set. Can i see the sign in request and response headers?
a
I'll be honest, I am not sure how I would capture and share that with you 😣
is that something I can grab from firefox?
ok...i think i might have what you're looking for: here are the request headers for a magic link:
Copy code
POST /auth/signinup/code HTTP/1.1
Host: api.site.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.site.com/
content-type: application/json
fdi-version: 1.15
rid: thirdpartypasswordless
Content-Length: 25
Origin: https://www.site.com
Connection: keep-alive
on the POST to the api to consume the magic link, here is the request headers:
Copy code
POST /auth/signinup/code/consume undefined
Host: api.site.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.site.com/
content-type: application/json
fdi-version: 1.15
rid: thirdpartypasswordless
Content-Length: 125
Origin: https://www.site.com
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
and firefox says there was no response data available for this request
at that point, the user was redirected back to /auth
Is it possible there is a 
www.site.com
vs 
site.com
issue with DNS? website_domain is 
https://site.com
, but DNS is set up to forward to 
www.site.com

https://cdn.discordapp.com/attachments/1100684697354391633/1100693760964313129/image.png▾

r
ohhh. No response data avaialble means that your backend crashed / closed the connection early. Is there any backend error stack trace?
a
It's on heroku, and I'm not seeing any crashes when I'm running tails on the container
r
whats the http status code you are getting from the /consume API?
a
200
r
and the response headers?
a

https://cdn.discordapp.com/attachments/1100684697354391633/1100695543098916974/image.png▾

r
i mean in the response headers as seen on firefox
a
looks like i'm getting a 308 response at 
site.com
followed by a 200 to 
www.site.com
r
your API layer is returning 308?
that's odd.. seems like an infra issue
a
here is the verify request as seen from firefox on the front end: request:
Copy code
GET /auth/verify?rid=thirdpartypasswordless&preAuthSessionId=ulqRUMYjXgKYutx_ssysA-ZuvNmhtY8HbFxHCg5Bdcg= HTTP/2
Host: www.site.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: sIRTFrontend=remove
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
and response:
Copy code
HTTP/2 200 OK
accept-ranges: bytes
access-control-allow-origin: *
age: 3734
cache-control: s-maxage=0
content-disposition: inline; filename="index.html"
content-type: text/html; charset=utf-8
date: Wed, 26 Apr 2023 08:09:50 GMT
etag: "a5ccb04565e5e19340b71b936d7a34e6"
server: Vercel
strict-transport-security: max-age=63072000
x-vercel-cache: HIT
x-vercel-id: fra1:fra1::b7vnx-1682496590967-706bceefd34d
content-length: 644
X-Firefox-Spdy: h2
r
thats the frontend app. but what about the API call?
a
according to heroku, 
method=POST path="/auth/signinup/code/consume" host=api.site.com
is returning a 200
r
right. WHat is the frontend seeing though?
a
after the user clicks on the magic link, which is 
site.com/auth/verify?...
1. the front end sees a 308 response. 2. then the frontend calls the same magic link with a www up front: 
www.site.com/auth/verify?...
and gets a 200 response. 3. Immediately after that, the frontend does a GET to 
site.com/auth/
that is initiated by main.4602XXXXXX.js, and that gets a 308 response. 4. Then the frontend does a call to 
www.site.com/auth/
and that gets a 304 response
r
whats the value of websiteDomain that you have set? It seems the right value to set is 
www.site.com
, but you have set it to 
site.com
a
let me try to change it
r
on the frontend and the backend + clear all cookies / localstorage and relogin and then try
a
it still kicks me to /auth
i need to run for a bit. if you have any ideas in the meantime, i'll tweak when i get back. thanks for your help so far!
r
whats the cookie store on the frontend after login?
a
@rp_st

https://cdn.discordapp.com/attachments/1100684697354391633/1100714213690839081/image.png▾

r
which version of the backend and frontend SDK are you using?
can you show me the consume code API's request and response headers via a screenshot please?
a
Copy code
❯ npm view supertokens-auth-react version
0.31.5
Copy code
❯ pip show supertokens_python
Name: supertokens-python
Version: 0.11.13
r
right. You need to update your backend SDK to be >= version 0.12.0
update it to the latest one: 0.12.8
a
i updated the backend. the issue persists.
i acknowledge fully my ignorance here, but I only see a call to /auth/signinup/code/consume on the API side, and I am not sure how to go about finding those headers
the logs generally show a 200, but I know that's not super helpful
r
what do you mean you call it on the API side?
That API needs to be called from the frontend
a
ugh i see it. hang tight
you want a screen shot instead of copy/paste?
r
screenshot
a

https://cdn.discordapp.com/attachments/1100684697354391633/1100718443168284712/image.png▾

r
and what are the request headers?
a

https://cdn.discordapp.com/attachments/1100684697354391633/1100718583975252058/image.png▾

https://cdn.discordapp.com/attachments/1100684697354391633/1100718708504137788/image.png▾

r
the request headers i mean
not the request body
a
one screenshot up
r
ah right. sorry
which version of the frontend SDK are you using again?
a
Copy code
❯ npm view supertokens-auth-react version
0.31.5
r
can you run 
npm view supertokens-website version
?
whats in your package-lock.json?
a
good point. package lock is 
"supertokens-auth-react": "*",
, which probably isn't ideal
its on vercel, im not sure how to find out which version it's using
r
right. Can you use make sure that you use the latest version of supertokens-auth-react ?
a
have you realized yet that I've only the slightest idea what im doing
r
yup. No worries though. It seems overall setup correctly..
just might be issues with version mismatch
of backend and frontend SDKs
a
I changed package.json to 
"supertokens-auth-react": "latest"
and ran 
npm install
, and it gave me this:
Copy code
❯ npm install
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'supertokens-auth-react@0.30.2',
npm WARN EBADENGINE   required: { node: '>=16.0.0', npm: '^8' },
npm WARN EBADENGINE   current: { node: 'v18.16.0', npm: '9.5.1' }
npm WARN EBADENGINE }
r
can you try with 
npm install --force
?
a
it gave the same thing
r
can you run 
npm i supertokens-auth-react@0.31.5
a
done
r
ok now try
a
so as far as i can tell, vercel doesn't have a way for me to drop into a shell, so im not sure what version of st-auth-react is getting installed when package-lock just says "latest"
r
you can do some googling to figure this out
a
...i'm going change latest to 
0.31.5
and try to deploy it that way
but first i need to step away for a bit
ok i got excited and didnt go run my errand
but it worked!
i had to force the update on npm
r
Right
a
you're doing god's work, rp
r
Cheers 🙂
5 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