Hi! I am using Angular, and I replaced the HttpCli...
# general
d
Hi! I am using Angular, and I replaced the HttpClient with fetch. My understanding is that Session.init() is supposed to add interceptors to fetch to send session data along with each http request. Is my understanding correct? If it is, then how can I debug to figure out why session data is not being sent when I make a fetch request?
r
hey! yes you are correct.
The fetch interceptors added automatically do the session related tasks.
The most common reason for session tokens not being sent is that you are calling supertokens.init at the wrong part of your code. You want to call it (once globally) before any API call is mode.
If you are doing that, then please enable debug logs and show the output of the logs
d
I think I am doing that. Stupid question, but how can I enable the debug logs in Angular?
d
Thanks!
Sorry, ignore my comments. It looks like the interception is happening. The 400 was because the server throws an error because the session is not found.
So next question: my understanding is that calling the "verifySession()" handler on the backend is supposed to append the session to the request, so I can get it in my next handler with request.session. Is that not correct?
r
that is correct.
d
Thanks. Can you help me make sense of the backend logs? message: "middleware: Not handling because no recipe matched" message: "getSession: Started" message: "getSession: rid in header: true" message: "getSession: request method: get" message: "getSession: returning undefined because idRefreshToken is undefined and sessionRequired is false
r
that means cookies are not being sent by the browser. This can happen if the interceptor is not applied on the frontend, or if the cookies are not set by the browser on login. Can you send a screenshot of the set-cookie header in the response of the login API?
d
I am not using the login API. I am creating a session myself based on the Firebase token. I can send a screenshot of the request to my API, though. Just a sec...
Sorry, I can also send a screenshot of the response to my session creation. Will do that.
I am making this call in my BE:
Copy code
await Session.createNewSession(response, uid);
I assume that it attaches the necessary data to the response, right?
r
right.. so it's not attaching the cookies in the response. Are you already sending the response before calling createNewSession
d
No. Here is the entire handler in its current state:
Copy code
if (!request || !request.body) {
      throw new Error(`Empty request`);
    }

    const body = request.body as TokenBody;
    if (!body.claims) {
      throw new Error(`Missing claims`);
    }
    if (!body.token) {
      throw new Error(`Missing token`);
    }

    let uid;
    if (!!request.session) {
      uid = request.session.getUserId();
      if (uid !== body.claims.user_id) {
        throw new Error('User ID does not match');
      }
    } else {
      uid = body.claims.user_id;
    }

    const sessionHandles = await Session.getAllSessionHandlesForUser(uid);
    const hasSessions = sessionHandles && sessionHandles.length > 0;

    if (hasSessions) {
      // No session is attached, but one exists, so we'll use that
      // const info = await Session.getSessionInformation(sessionHandles[0]);
    } else {
      // No session exists, so we need to create a new session
      uid = body.claims.user_id
      await Session.createNewSession(response, uid);
    }

    response.status(200).json({status: 'ok'});
r
and are you sure that
createNewSession
is being called? Can you add a console log right above it?\
d
Yes, I'm sure, but I'll send you the log and the session data so you can see it.
r
hmm. So the API is calling
createNewSession
, but the cookies are not being set in the response.. that's weird.
is there something that would strip away headers from the response? like nginx or something that you are running?
oh, and what are the request headers in this API call
d
Ah! It looks like you have helped me find the problem. In my attempt to reuse the session (see code above) createNewSession does NOT always get called. I will try to find in the docs where it explains how to attach the session cookie myself. (Or, if you can nudge me in the right direction... 😆)
r
Well, there is no ready way to attach cookies yourself. You will have to make them yourself. Which is hard.
d
Just in case, to answer you other question, here are the headers:
r
But why not just call createNewSsssion?
The request headers look fine
d
Ok, I think I see the problem. I am calling my /signin endpoint each time the Firebase authentication is updated, instead of just calling it when the user actually signs in. It is in that endpoint that the session gets created. Because I call it too often, that is why I had the funky logic in my code above (which really doesn't seem right to me). So I now understand, it is when the session gets created the first time that the cookie gets sent back with the response, and that is when the "cycle" (if I can call it that) gets started. Let me update my frontend code, then. Thanks for the tips!!!
r
Great!
d
Am I reading correctly that the FE is indeed sending the cookie?
doRequest: start of fetch interception shouldDoInterceptionBasedOnUrl: toCheckUrl: http://localhostxxxx doRequest: Value of doNotDoInterception: false doRequest: Interception started getIdRefreshToken: called getIdRefreshToken: returning EXISTS: bd48cdb1-4df6-430b-969e-9e52d58a50f8 AntiCsrfToken.getToken: called getAntiCSRFToken: called getIdRefreshToken: called getIdRefreshToken: returning EXISTS: bd48cdb1-4df6-430b-969e-9e52d58a50f8 getAntiCSRFToken: returning: null AntiCsrfToken.getToken: returning undefined doRequest: Adding credentials include doRequest: Adding rid header: anti-csrf doRequest: Making user's http call doRequest: User's http call ended getIdRefreshToken: called getIdRefreshToken: returning EXISTS: bd48cdb1-4df6-430b-969e-9e52d58a50f8
r
Well, the frontend SDK doesn’t send the cookie. The browser does it automatically. As long as it’s set correctly.
But the frontend SDK does think that the session exists
d
So it's safe to assume that the cookie is being send from the browser to the backend. For some reason, the backend does not see it...
middleware: Started middleware: requestRID is: anti-csrf middleware: Checking recipe ID for match: session middleware: Not handling because no recipe matched getSession: Started getSession: rid in header: true getSession: request method: get getSession: returning undefined because idRefreshToken is undefined and sessionRequired is false I wonder what the "no recipe matched" error means...
r
The no recipe matched just means that it will forward to request to one of your APIs.
Can I see the response headers for when you call createNewSession?
d
38 Views