Are the frontend auth routes from the NextJS SDK N...
# support-questions
m
Are the frontend auth routes from the NextJS SDK Next-specific or able to be used with any backend as long as the config is set correctly? As far as I can tell it seems like everything just uses the same stuff from the React package, with some extra stuff added for routing & SSR support But... I'm deploying on Vercel with a Next frontend but a backend api written in a different language (Python, FastAPI), and I can NOT get APIs nor signout to work correctly for some reason. Signup and signin works fine, but trying to call any backend service from the browser with an axios request throws 401. I've tried wrapping axios outside the component function and inside useEffect(..., []). Also, after calling logout, going to /auth again doesn't redirect to the signin screen unless I manually clear browser cookies. Protecting a page with the ThirdPartyEmailPasswordAuthNoSSR also doesn't redirect to signin after I've signed out, unless I manually clear the cache. The backend endpoints work fine when tested from Insomnia. I thought it might just be an issue with dev mode but I've tried fully building it too.
r
hey @mlegls
So if i understand correctly, you have a nextjs frontend + a different backend process right (not using nextjs' api)?
m
Right. For the backend I just followed the documentation's instructions for FastAPI for Python
r
yea makes sense..
and you don't need to setup the nextjs' backend stuff then.. essentially, you don't need to use supertokens-node at all.
m
Right, I took all that stuff out
r
cool
can you enable debug logging in the python SDK and then show me the logs on app start + when you are querying the sign out API?
m
how do I enable debug logging?
r
see the troubleshooting section in the docs
m
oh hmmm I think I fixed the issue myself just by changing the api route from 127.0.0.1 to localhost lol
thanks for the help anyways!
r
hmm! cool
m
I wonder why that's an issue though
r
well.. are you putting your API domain as 127.0.0.1?
apiDomain
m
I mean I changed it in frontendConfig. It was apiDomain: "http://127.0.0.1:8000" and I changed it to apiDomain: "http://localhost:8000"
r
right. So if you are querying localhost, then the apiDomain should be that.. else the interceptors won't be applied on the frontend and it won't work
m
oh I see
hmm... it seems like even though the login redirect works now, the api call still doesn't
r
the cookies are not being sent. That;s the problem
here is a list of reasons why that may happen: https://github.com/supertokens/supertokens-website/issues/68
please make sure you go through this list and check each item
m
I've gone through each of the items but still can't figure out what's wrong. I've tried running the request with fetch instead of axios from the frontend, and the browser's dev tools say the request is initiated from recipeImplementation.js, so I'm pretty sure it's being intercepted. Also, the same endpoint works perfectly fine from Insomnia. I can see that the Insomnia request includes the sAccessToken cookie though, while the browser request doesn't.
Looking at the logs, the browser's automatic "refresh" request also fails with 401, and also doesn't contain the access token cookie
r
\Can you show me the response headers and request headers for the sign in API call? (a screenshot would do)
m
I tested some more, and it actually works fine from Chrome, but not from Safari...
r
I see. So the issue there is that the websiteDomain doesn’t have anything common with the apiDomain value.
So safari rejects third party cookies by default
This can be solved by making both apiDomian and websiteDomain work on localhost (with different ports)
And in prod, by making them have different sub domains
For example, websiteDomain can be example.com and apiDomain can be api.example.com
4 Views