https://supertokens.com/ logo
Join Discord
Powered by
Can I use verifySession in a way that the route is...
# support-questions-legacy
l
Can I use verifySession in a way that the route is also accessible by users without a session? I thought 
verifySession({ sessionRequired: false })
would do the trick, but requests without a session get a 401. This is a problem for me, because I'm using https://telefunc.com for client <> server communication. The tool uses one route, whereas some requests need data from a possible existing session and some don't. Is there maybe another way without using verifySession?
r
Hey. Using sessionRequired: false is the correct way
The only time this returns a 401 is when a user has a session, but their access token has expired
Therefore the session needs to be refreshed
As opposed to a user who doesn’t have a session at all. In this case it will allow the api to run except that the session object is undefined
l
Hmm ok I'll investigate a bit more
Thanks for all the help in the last 2 days!!
Sometimes the automatic refreshing of the accessToken works, and sometimes I just get back a 401. Can't really work out, what the problem is. Just really unpredictable. To test better, I decreased the accessToken lifetime to 15s. And on sometimes the refreshing works and I can have minutelong session, but sometimes not. Noticed, that Session.doesSessionExist returns false immediately after the session creation (when the 15s token is still valid). What could be the cause for that?
r
which frontend sdk of ours are you using?
l
I'm using supertokens-web-js
r
right. Can i see the request and response headers for the sign in API call? Chrome screenshot will do
l
Yes, I'll prepare them. But I just found something: When I create the new session and wait, until the accessToken expires. Then sIRTFrontend is set to remove. The accessToken also gets removed. When I delete the sIRTFrontend cookie and refresh the page the refreshing works. It also never stops working. Not even after multiple refreshes. What functionality sets the sIRTFrontend cookie?
r
we add interceptors to your networking lib and when the interceptor detects that session tokens are returned, it sets the correct value for sIRTFrontend
l
What does it mean when it's set to remove?
r
it means that the frontend thinks that no session exists.
l
when is that supposed to happen?
r
when you call the sign in function from the frontend.
The API that returns session tokens
l
I'm not doing that. My current flow looks like the following: I sign into github with my own implementation of the OAuth flow, which redirects the user to a new tab. I create the session on the server using createSession() and add the oauth token to the sessionData. The new tab is closed and the session exists for the livetime of the accessToken
r
Right. So the api that calls createNewSession, I want to see the response and request headers for that
l
The session creation is happening in the express backend. The Frontend get's to know that the user is logged in because of the values the telefunc functions return
r
I’m confused. Doesn’t the frontend call the express backend api which creates the new session?
l
Yes but not through the supertokens sdk
r
That’s fine
So whatever that api call is, I want to see the request and response headers of that
l
Alright
Copy code
{
      "params": {
        "headers": [
          "Host: localhost:3000",
          "Connection: keep-alive",
          "Upgrade-Insecure-Requests: 1",
          "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36",
          "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
          "Sec-Fetch-Site: cross-site",
          "Sec-Fetch-Mode: navigate",
          "Sec-Fetch-User: ?1",
          "Sec-Fetch-Dest: document",
          "sec-ch-ua: \"Not_A Brand\";v=\"99\", \"Google Chrome\";v=\"109\", \"Chromium\";v=\"109\"",
          "sec-ch-ua-mobile: ?0",
          "sec-ch-ua-platform: \"macOS\"",
          "Accept-Encoding: gzip, deflate, br",
          "Accept-Language: de, en;q=0.9",
          "Cookie: sIRTFrontend=remove"
        ],
        "line": "GET /services/auth/github-oauth-callback?code=29bba76e378dbfb47e9c HTTP/1.1\r\n"
      },
The request
r
Can u show me the screenshot on chrome?
l
bit tricky because of the new tab opening thing
got it to work
r
Hmm. This already has the access token set in cookies.
So I’m not sure what you are doing
l
ok sorry wrong one
r
So it seems that our interceptor is not applied to this api call. What’s the domain for this api call? And what’s the value of apiDomain set on the frontend?
l
uhh ok that sounds like a really good hint
I set the frontend and backend api path to /session
r
What about the apiDomain?
l
My api routes are at /
r
That’s not the issue
l
r
As long as you have the same apiBasePath on the backend and frontend
l
(in the frontend location.origin)
r
And what is the value of location.origin?
And which api are you calling? The domain of the api
l
r
Even on the callback screen, the location.origin is localhost:3000?
l
I set it to "http://localhost:3000" now. Should have been that with location.origin, but I'll test with the fixed string
r
You also need to make sure that you are calling supertokens.init on the frontend in the callback page before the api call is made
l
That is happening
I got an error when that didn't happen
r
Can you enable frontend debug logs and show me the output when the api call is made?
l
yes
r
Can you send me the logs that are generated just during the api call?
l
The user get's redirected to my app after successful github authentication. In the request of that page the session gets created
r
There is a preserve log button on chrome
Maybe go through this list first before I can help more 🙂
Intuitively, it seems that you are not calling supertokens.init before making the api call.
But I may be wrong.
l
Ok thanks, I'll work through that
So could the problem be that the session get's created in the page request?
The frontend can't be initialized before
r
It gets created in the api call you are making
The problem is that our interceptors are not being applied to the api call
This happens cause of misconfiguration of apiDomain vs the url that you are querying
Or cause you have not called supertokens.init on the app yet
If you have specific questions, I’d be happy to help. I feel like I have spent enough time debugging with you and the GitHub issue about exists already.
l
Yes, you're right
Thanks a lot man!
FYI: You've been right, I created the session on a "API-only" route. The user got directly redirected to that route and on that route no SuperTokens.init() call was made. I'm creating the session now with a fetch call from the frontend even before it is needed and before the oauth redirection cascade. Everything works as expected now 🙂 Can the frontend also recognise that a session is created if this creation is not triggered by a fetch call from the frontend? Would it work if I redirect the user to a new page and the session get's created in that page request (so not by calling an API endpoint and so for not utilizing the fetch interceptor)? Supertokens would only be initialized, after the browser processes the response. But the response would include all necessary headers.
r
Yes. That can work, if on the frontend, you call the Session.attemptRefreshSession function when the page loads (I think the name of the function is that, but if not, it’s similar)
l
Alright, thanks 👍
Everything works as expected now, in Chrome... Safari seems to have problems. Can my multi tab oauth flow be a problem in Safari? I'm creating the session in one tab and it survives refreshes. When I navigate to the oauth provider in a new tab and get redirected to my frontend route (also in the new tab), the behaviour is different from the behaviour in chrome. After the oauth flow finished and the new tab shows my frontend route, but the sIRTFrontend cookie is again set to remove.
r
Hmm. Usually safari issues are due to use cross site cookies. But I think in your case, the api and website domain values are the same right?
l
Yes
r
Hmm. So there shouldn’t be any issue as such. Can I see the request and response headers for the request that creates a session?
l
yep
Also added this snippet, which generates this output. Getting the access token payload works, until the accessToken needs to be refreshed. When /session/refresh is called by the frontend sdk it returns a 401 and the accessToken payload can no longer be read
sIRTFrontend is then set to remove
r
So I see a weird thing. Why is the sameSite value none in cookies?
Have you explicitly set it to none on the backend?
l
these are my configs
r
The value of apiDomain should be localhost:3000 as well
Make that change, and try again.
l
Uh ok males sense
Ok just checked and that was the problem. Now it works :))
Thanks a lot for all that first class support! Can I do anything for you? Something like writing a review anywhere? Or do you have a buymeacoffe ^^
r
You could tweet about us and tag @supertokensio in it
l
Alright, I‘ll do that 🙂
FYI: Just checked again and I used the config that was generated by the tool on your page. Which has the apiDomain for the appInfo set to the remote apiDomain. Might be a bit confusing
r
That’s cause you set it to that value in the form above
l
Ahh ok I didn't get that the apiUrl of the backend is automatically added... Thought that would be the place to put in the supertokens api domain 😅
7 Views
PreviousNext
Powered by