https://supertokens.com/ logo
Join Discord
Powered by
Hi, I am trying to implement a flow where we have ...
# support-questions
p
Hi, I am trying to implement a flow where we have 2 apps. One app does not use supper tokens, but the other does. Both are on the same domain. The app that does use supertokens uses the passwordless recipe and all@works fine. The second app uses its own login but has an endpoint that calls create session and returns the cookies to be used in the second app. Everything works fine in postman.. the cookies are returned and the api calls to the second app work. When we try this from the browser it does not work as the cookies do not get stored.
r
hey @PitchAsh
can you: - enable frontend logs and show me the output on app start, and when you make the login call - show me a screenshot of the set-cookies header in the response of the login API (as seen on chrome)
p
Does the app that calls the endpoint that impersonates using create session need to implement supoertokens sdk to make sure cookies are stored correctly?
r
Yes. On the frontend it does.
p
Currently we only have supertokens embedded in the second app that uses it for auth
So even though the first app uses Its own auth.. we need to add supoertokens to ensure the returned cookies get stored?
r
we have a sessions only SDK -> supertokens-website which you can use for the app in which you use us just for sessions.
> So even though the first app uses Its own auth.. we need to add supoertokens to ensure the returned cookies get stored? Yes. supertokens-website repo. It has no login UI or anything. Just session
p
Right.. this app doesn’t actually use the session.. it just needs to store it
I assumed that since the session is returned using “setcookie” there would be no need to at it to that app
r
uhmm. So you can get away with it. But you have to make sure: - To include credentials when making requests from the frontend - There would be no way to check if a session exists without querying an API, or storing some other token on the frontend which is in "sync" with session creation and removal (essentially what our SDK does) - Session refreshing would not be automatic. So if the access token expires, then the user would be in a stuck state.
p
Right but the session only needs to be used on the second app… so all the refresh would happen when the session is used
So the flow is … login to admin.our domain.com… call “impersonate” api… which calls “createSession” on the be. Then redirect to public.our domain.com which shoukd then use this session
So… this all works in postman and I can see admin.domain.com/impersonate returns setcookieheaders
And in postman calling public.domain.com/authed/endpoint then works fine
But on the browser…. The cookies don’t get stored when calling admin.domain.com/impersonate
r
can you show me a screenshot of the set-cookie header?
p
one sec
This is the api call to impersionate.. made on the admin app.. you can see the setcookie headers.. ill expand the accesstoken..
not seeing SameSite=Lax now.. i was seeing that earlier..
ok so postman is showing samesite=lax
The app that calls this api is hosted on admin-dev.mypetportal.co.uk
We have a second app hosted on pay-dev.mypetportal.co.uk, and that app uses passwordless and works fine
both apps call the same api on gateway-dev.mypetportal.co.uk
So, the idea is to login to admin.. impersonate a pay-dev user, and redirect to the pay-dev app
So pay-dev app users login using passwordless.. admin uses login using our own login.. and can then impersonate pay-dev users
r
So on the browser, when you query the API (from the app that doesn't use supertokens' frontend SDK), are you setting credentials include in the header?
p
the admin app uses its own login, api-key, and session token header
r
so the admin app doesn't use supertokens?
p
correct
r
and the other apps do..
ok got it
p
so.. login to admin app.. call impersonate which returns setcookie sessions.. then use that on the supertokens app..
r
when you call the API that creates a new session in the admin app, what is the set-cookie response in that? (I would like to see the screenshot on chrome for the response headers as it points out if there are issues)
p
this way super admin can login to the public app impersonating a supertokens user
you can see the token in postman above.. im not sure how to get that from chrome..
actually inonly have safari and brave browsers
r
hmm
Ah i think i found it
so two issues: - the set-cookie from the admin app has the domain as 
Domain=mypetportal.co.uk
. As opposed to 
Domain=.mypetportal.co.uk
- Also, as you mentioned, no samesite=lax
p
well.. it depends where i look.. postman shows something different
r
whats the config on the admin app's backend?
for supertokens.init
ah wait. its the same backend for both. nvm
ok so the cookies seem fine
p
this is the browser console showing the impersonate api call made to the admin app
so setcookie is there in the response headers... all looks ok.. but no cookie stored
r
the cookie will be stored against the API domain.
Can you visit the API domain's URL on your browser and see the cookie store there?
p
i cant see any cookies stored under anythig for that domain
r
hmm. this is strange
it;s really hard to debug without the SDK logs..
can we get on a quick call now/
p
what sort of call?
r
voice + screen share
p
in discord ?
r
i prefer zoom
p
sure send me a link?
r
yup
p
Thanks for the call.. just to confirm.. which header did you suggest we try adding on the impersonate call?
r
credentials include header
p
We added the credentials header on the request and this then meant the accesstoken and idrefresh token made it into the browser. Bad news is when redirecting to the public app it will didn’t work, I think because the frontend headers were not there so the sdk in the other app didn’t like it.
r
So the headers not being set is OK cause the frontend SDK on the other app would just refresh the session and add the headers
p
We then added the sdk to the admin app… even though it’s not used by that app. Good news is that with the sdk added to that app all the relevant cookies get set in the browser and redirecting to the public app now works
r
hmm.
p
So with the sdk included and just initialised but not used… this seems to ensure everything works.
To be honest I’m ok with this… we plan on switching the admin app over to supertokens anyway at some point
r
well, ok fair.
p
We want to keep the admin app using username + password.. and public app using passwordless. These will sit together ok in the same backend? Its 2 seperate sets of users isnt it?
@rp maybe you missed this last question? Passwordless and Password recipies can coexist on the same backend ok right?
r
Ah yea. I had missed this
Yes. They can. They will have different user pools
However, their sessions setting will be the same
Since you can do session.init just once in the recipeList which is shared across the other recipes
p
Great.. I think that should be ok.. Im now going to look at a migration where we spend a few weeks capturing the passwords of the users with the current login and createing new supertokens users.. then after a few weeks we can switch over the signin method from firebase to supertokens.. anyone who logs in at least once over the next few weeks will be seemless.. anyone that doesnt we can force them through a password reset flow..
PreviousNext
Powered by