https://supertokens.com/ logo
Join Discord
Powered by
Hi! I am running into a problem on the backend......
# support-questions-legacy
d
Hi! I am running into a problem on the backend... My sessions are getting created just fine, and I can use them on the frontend without any problems. However, when I try to use the verifySession() middleware in the backend, it is returning 
session = undefined
. I suspect that it is a configuration issue. I am using Firebase Functions, and this is a different function (so a different route / endpoint). Still, I have not been able to successfully configure... Any thoughts?
r
Hey!
Can you please enable backend debug logs and show the output?
when you call the API
d
Sure. Here it is. Note that I changed the path from 
/auth
to 
/cats
because it is a different route. That said, I get exactly the same result when the value is 
/auth
. I'll revert and double check the logs, though.
Copy code
i  functions: Beginning execution of “cats"

Started SuperTokens with debug logging (supertokens.init called)
appInfo: {"appName":"SuperTokens Demo App","apiDomain":"http://localhost:5001","websiteDomain":"http://localhost:4200","websiteBasePath":"/auth","apiBasePath":"/","apiGatewayPath":"/supertokens-demo-20220805/us-central1/cats"}
framework: express
"session init: antiCsrf: NONE
session init: cookieDomain: undefined
session init: cookieSameSite: lax
session init: cookieSecure: false
session init: refreshTokenPath: /supertokens-demo-20220805/us-central1/cats/session/refresh
session init: sessionExpiredStatusCode: 401
getSession: Started
getSession: rid in header: false
getSession: request method: ge
getSession: returning undefined because idRefreshToken is undefined and sessionRequired is false

Session undefined
r
Right. I see that you have passed sessionRequired as false in the verifySession function.
Can you remove that flag and call the API once again? What is the output? Do you get back a 401 on the frontend?
d
Yes, 401. That is why I added the "false", to try to see what was happening. I will remove that config and grab the logs anyway.
r
Got it. So the frontend is not sending the cookies for some reason. Are you using axios on the frontend?
d
Ohhhh. Nope, no axios, but I think perhaps I see the problem... Let me try something.
r
ok
d
Ok, never mind. Looks like my theory was not correct. I will enable logs on the frontend now to try to try to confirm whether or not the cookie is being sent.
r
okay
Also can you send me a screenshot of the set-cookie response header when you call the login API?
d
Sure. Here are the logs. I don't know what everything means, but it looks to me like the cookie is being sent. (I need to send a screenshot because Discourse is telling me my message is too long...
r
Can you take a screenshot from chrome? it tells you if it didn't set cookies
oh i meant the screenshot of the set-cookie header in the response
in neteork tab
When it redirects you back to /auth/callback/google, do you not call supertokens.init in that route?
d
I believe I am, but let me check...
r
these are response headers from which API call?
d
The API that is returning the 401
r
oh no. Can i see the response headers for the API that gets called on /auth/callback/google?
d
Just so you know, I am able to get the session object, so I think the cookie is being set correctly.
Yes, sure...
r
> I am able to get the session object On the backend?
d
On the frontend. It is on the backend that I am having trouble.
Here are the logs, in series...
r
right yea
d
Copy code
init: called
init: Input apiBasePath: /supertokens-demo-20220805/us-central1/auth
init: Input apiDomain: http://localhost:5001
init: Input autoAddCredentials: true
init: Input cookieDomain: undefined
init: Input isInIframe: false
nit: Input sessionExpiredStatusCode: 401
init: Input sessionScope: localhost
doesSessionExist: called
getIdRefreshToken: called
getIdRefreshToken: is removed
doRequest: start of fetch interception
Copy code
shouldDoInterceptionBasedOnUrl: toCheckUrl: http://localhost:5001/supertokens-demo-20220805/us-central1/auth/signinup apiDomain: http://localhost:5001 cookiDomain: undefined
doRequest: Value of doNotDoInterception: false
doRequest: Interception started
getIdRefreshToken: called
getIdRefreshToken: is removed
doRequest: Adding credentials include
doRequest: rid header was already there in request
doRequest: Making user's http call
doRequest: User's http call ended
doRequest: Setting sIRTFrontend: 1fd...
setIdRefreshToken: called
getIdRefreshToken: called
getIdRefreshToken: is removed
setIdRefreshToken: setting: 1fd...
setIdRefreshToken: firing SESSION_CREATED event
doRequest: Setting sFrontToken: ey...
FrontToken.setItem: called
setFrontToken: called
getFrontTokenFromCookie: called
getIdRefreshToken: called
getIdRefreshToken: returning EXISTS: 1fd...
doRequest: start of fetch interception
Copy code
shouldDoInterceptionBasedOnUrl: toCheckUrl: http://localhost:5001/supertokens-demo-20220805/us-central1/auth/user/email/verify apiDomain: http://localhost:5001 cookiDomain: undefined
doRequest: Value of doNotDoInterception: false
doRequest: Interception started
getIdRefreshToken: called
getIdRefreshToken: returning EXISTS: 1fd...
AntiCsrfToken.getToken: called
getAntiCSRFToken: called
getIdRefreshToken: called
getIdRefreshToken: returning EXISTS: 1fd...
getAntiCSRFToken: returning: null
AntiCsrfToken.getToken: returning undefined
doRequest: Adding credentials include
doRequest: rid header was already there in request
doRequest: Making user's http call
doRequest: User's http call ended
getIdRefreshToken: called
etIdRefreshToken: returning EXISTS: 1fd...
r
what about the set-cookie headers in the response from the API to consume the code?
d
IIUC, that is the one I pasted above. Looks like the header is not there.
I.e. the response I pasted above is the response when I call the API that is giving the 401. Is that what you meant?
r
ah no no
so when the user is navigated to /auth/callback/google, that page makes an API call right?
d
No. Ther user navigates to a different page, which makes a call to a different API, i.e. my own custom API that I am trying to secure with SuperTokens by using verifySession(). Hope that makes sense.
r
huh.. so in which API does the session actually get created?
d
I have 2 different Firebase Functions, so I guess you could call them 2 separate APIs. The session gets created in the 
/auth
API. The API I am trying to secure now is the 
/cats
API.
r
right. So in the 
/auth
API which creates the session, can i see the response headers for that one?
d
Ah! Ok, yes.
So that would be the call to signinup?
r
Hmm. Can I see all the info? path, method, request and response headers
d
That's all the Reponse Header shows. I can show you the Request Header...
r
so thats strange. You somehow already have a session when that API is called?
Which API is this for again?
d
This is for the 
/auth
API when I sign in. This is the call to 
signinup
.
r
so i wonder how a session already exists when this API is called..
Cause the signinup API is supposed to create a session.
d
Ok, I think I see what you mean... Let me check again.
Here is the call to `supertokens.com/dev/oauth/redirect-to-provider`:
r
right.. so not this API
d
Then it calls Google...
r
yes
d
Then 10,000 more calls to Google junk...
Then 
supertokens.io/dev/oauth/redirect-to-app
r
right.
Also, you should consider using your own google credentials instead of using our dev / docs ones.. that way you wont have supertokens.io in the middle..
d
Ok, it makes 2 calls to signinup. I gave you the 2nd one. Here is hte first one:
Yeah, I will be changing that soon, but thanks for the reminder.
r
this is the POST or OPTIONS one?
d
Ah, you are right, this is the OPTIONS preflight one.
This is the POST response:
r
ok perfect! so it is doing the set-cookie thing
and it seems that the cookies are being set properlty
Can I see the full response headers?
d
Ok, good to know.
Sure.
r
you cut it in the middle
d
r
can is see the URL on which you are querying this? The full path
what is your apiDomain and websiteDomain value set to?
on backend
d
Request URL: http://localhost:5001/supertokens-demo-20220805/us-central1/auth/signinup
appInfo: { appName: "SuperTokens Demo App", apiDomain: 'http://localhost:5001', websiteDomain: 'http://localhost:4200' apiBasePath: '/auth', apiGatewayPath: '/supertokens-demo-20220805/us-central1', websiteBasePath: '/auth' },
r
Hmm. And finally, when you call the API that uses verifySession, what are the request headers there?
d
r
and headers?
d
r
send chrome screenshot of them please
d
You are too quick for me. 🤣
r
oh.. so it's not applying the interceptor to that request?
cause otherwise you would see a 
rid: ..
header as well
d
Hmmmm. I thought it was... That is what I checked earlier. I will have to check again.
r
yes please.
is using axios, then make sure to add axios intercptor
d
No axios.
r
if not using axios, make sure that supertokens.init is called before
d
Yes, it is being called in the app init.
Here it is, just in case...
r
can you console log before the init and before the API call and make sure the init is called?
d
Copy code
SuperTokens.init({
  appInfo: {
    appName: "SuperTokens Demo",
    apiDomain: 'http://localhost:5001',
    apiBasePath: '/auth',
    apiGatewayPath: '/supertokens-demo-20220805/us-central1',
  },
  recipeList: [Session.init()],
  enableDebugLogs: true,
});
Ok.
Yup, init is getting called before the API call.
r
are you using 
fetch
?
d
But... if I am reading this correctly, it is choosing not to intercept because of the URL:
Copy code
com.supertokens {t: "2022-08-22T06:52:15.884Z", message: "shouldDoInterceptionBasedOnUrl: toCheckUrl: http://localhost:9099/identitytoolkit.googleapis.com/v1/accounts:lookup?key=AIzaSyAQOYDj_1xqPQB7uiHnD9esHNZPjjpM_OA apiDomain: http://localhost:5001 cookiDomain: undefined", supertokens-website-ver: "13.0.2"}
Is that correct?
r
or some other way of querying?
d
I am using Angular HttpClient, but I think it is using fetch in the background. I can see logs like this:
Copy code
com.supertokens {t: "2022-08-22T06:52:15.883Z", message: "doRequest: start of fetch interception", supertokens-website-ver: "13.0.2"}
So it appears to be intercepting.
r
ohhh im not sure if we work with 
HttpClient
but if it uses fetch, i guess that works
d
Ok, I will try using fetch directly.
r
Also yea, it won't do the interception on 
http://localhost:9099
it will do interception when querying 
http://localhost:5001
since thats the apiDOmain you set
d
Can I set multiple domains?
BTW, that call to 9099 was something different. I am just asking out of curiosity...
r
> Can I set multiple domains? If they are sub domains, then yea.. see the multiple API domain docs
d
Ok, thanks.
Access to fetch at 'http://localhost:5001/supertokens-demo-20220805/us-central1/cats/fact' from origin 'http://localhost:4200' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
I thought this was supposed to be handled by the interceptor... or am I mistaken?
r
no. CORS is a backend setting.
You need to setup CORS properly. See the backend quick setup docs - it has a section about CORS
d
That was indeed the issue: HttpClient does not work out of the box. I had missed this because (1) I had misunderstood the previous interceptions (by misreading the logs, I had wrongfully assumed that HttpClient was using fetch in the background, and that SuperTokens was succssfully intercepting), and (2) I had not realized that cors was not set up properly, which also caused me further confusion. Thanks to your help, I was able to finally zero in on the actual problem. I am almost certain that I will be able to fix it now.
r
ok awesome!! We are working on a way that HttpClient will also work with SuperTokens. But until then, you need to use fetch or axios 🙂
d
Ok, cool. In the meantime, I can instantiate a custom HttpClient that uses fetch.
r
I guess that would work
d
Yes, it is working! Thanks again.
r
Nice!
159 Views
PreviousNext
Powered by