Hi, I'm using a library for generating a typed api...
# support-questions
d
Hi, I'm using a library for generating a typed api-client on my frontend (swagger-typescript-api), however it seems that the headers required by supertokens aren't set when using it. I don't understand why because the generated client uses fetch internally, which should be monkeypatched by supertokens (or so I understand) I also get an infinite loop of unauthorized requests. I am using the ThirdParty recipe. Do you know how I could fix this ?
r
Hey! Can you please enable frontend debug logs and show us the output of that during this sequence of API calls?
Also, it seems that the server refused the connection when the refresh API was called - can you call the refresh API manually via postman and see what happens?
d
thanks ! I will try the debug logs right now
there's a ton of output in there...
r
ok this looks fine. Can you enable backend logs and show me the output there?
d
everything does work when I don't use the generated client
okay !
Again, a lot of output
Here are the request headers
r
I see. So the browser is not sending the cookies.
Can you do the login request once and show me the response headers from it? Specifically, I want to see the set-cookie header
d
okay! thanks for your time again
r
hmm this is strange - why is the header being sent twice?
i mean each cookie header being sent twice
does this happen even when you don't use the auto generated code?
d
Well actually I've just tried to NOT use the generated client again, and indeed I still get an error
This is weird because I had everything working fine before (when using fetch directly)
The one difference I can think of right now is using typescript
r
hmm. What is the apiDomian and apiBasePath that you have provided? This is very strange
d
Copy code
apiDomain: "http://localhost:8081",
        websiteDomain: "http://localhost:8080",
        apiBasePath: "",
        websiteBasePath: "/auth",
r
Hmm. Can you make apiBasePath =
"/"
and see if that helps?
d
I got the same error
r
how about making it
/auth
?
d
oh my I'm sorry the last few errors were my bad
r
hmm
d
when using fetch directly I inputted the wrong path
r
right i see.
d
so anyway it IS working when not using the generated client
r
right. And when not using the generated client, what is the login request's response headers?
d
Here I'm using fetch directly in my code
in this message there's a screenshot of the same request but with the generated client https://discord.com/channels/603466164219281420/998254279401951302/998257137476178033
r
I think the generated code is making the fetch call with credentials header set to false.
which tells the browser to not send the cookies
d
Copy code
private baseApiParams: RequestParams = {
        credentials: "same-origin",
        headers: {},
        redirect: "follow",
        referrerPolicy: "no-referrer",
    }
those are the default options of the generated client
r
ahh i see. Can you remove the
credentials: "same-origin",
part?
d
replace it with nothing ?
r
yes
just remove that key / value
d
that worked
thank you so much
r
cool!
d
thanks for taking the time with my problem again, so far I'm really liking supertokens btw
r
thank you :)) Happy to help
One more thing
the response headers that you are getting on login
it has set-cookie twice for each of the session tokens.
Which framework are you using on the backend?
d
fastify
r
Hmm. When you don't use the auto generated client, what does the set-cookie headers look like?
d
tbh I doubt that it will make a difference, because I'm only using the generated client after having logged in
I'll try though
r
yea i doubt too.. it may be an issue with our SDK setting the cookie headers for fastify
that's why im curious
d
yeah, I disabled the generated client but I think it's pretty much exactly the same as before
r
hmm ok thanks!
We will have a look at this.. it's odd.
But anyway, shouldn't affect the functionality.
d
indeed
gdluck with the debugging then
2 Views