https://supertokens.com/ logo
Join Discord
Powered by
Hey everyone, I am using passwordless flow to send...
# support-questions-legacy
m
Hey everyone, I am using passwordless flow to send password/email OTP's. Now I want to do some checks in my backend in 
consumeCode
section but I am unable to get the login type(phone/email). The reason I need login type is to determine what is the input I am getting and accordingly check for the relevant user in the backend. Can anyone please enlighten me here?
r
Hey
One of the inputs to the consume code api is preAuthSessionId
That can be used to get the login info (email or phone used) via the passwordless recipe’s function.
See the listCodesByPreAuthSessionId function
m
Thanks @rp_st
Also, I want to customise the response of 
/api/auth/signinup/code/consume
endpoint
instead of just using cookies, I want to return 
accessToken
for mobile clients
can we do that?
r
You can. But I would really recommend not to do that, or wait a week or so when we release header based auth. Manually sending back and handling the access token can cause a lot of bugs
m
this is kind of urgent, so a short term patch will work for me @rp_st
can you please point me in right direction?
r
What do you intend to do with the access token?
If you want to send it to a third party or something, then you should use the JWT instead
But if you really want to just use the session’s access token, then see the page about customising api response
m
Yeah JWT will do, the use case is that I have a cordova app. Now The SMS based OTP verification works but problem is that the cookie isn't setting because request is from localhost. And my auth domain is hosted at 
auth.example.com
.
So sub-domain session sharing and all works, but since multiple root domains are not supported right now, I can't use localhost in this case
same is the issue when we offer it to clients at 
xyz.com
and want to use the above 
auth.example.com
as central auth location
r
right. In this case, you want to redirect the user back to the original app from auth.example.com with the JWT in the query params
m
hmm.. ok. let me try that as well
@rp_st please also tell me the patch as well... just in case the ideal way is too long for our delivery timelines...
r
See the link i had sent you above. It shows you how to modify the API response
m
ok.. let me check that
thanks again for your help
you are a savior!!!
@rp_st sorry to bother you again, but I am able to get the JWT, but how do I get the refresh token in backend?
I see the express example for localstorage usage re-writes the Cookie headers, but I am unable to do the same in NextJS
any idea why that is the case?
@rp_st or is there any method using which we can get refresh tokens? I can see methods to get accessToken from Session, but not refresh tokens
r
you don't need to get the refresh token
once you have the jwt, send it to the target app
as a query param
on the target app, read the JWT and send that to its backend. The backend will verify the JWT and create its own session using our session recipe.
m
you mean I can get the session created to a different domain as well if I pass the JWT to backend? I don't think my cross domain example will work even if I do this
r
You will have to create a new session based on the sub claim in the JWT on the target app
So you will have two different sessions
One on auth.example.com
And one on xyz.com
m
hmm... this is a bit confusing at the moment. Just to summarise, even if my API is hosted at 
auth.example.com
, my JWT token that I received on 
xyz.com
can request for session to be generated at 
xyz.com
using that JWT token?
if that is the case.... this would solve LOT of issues
r
on xyz.com, you will need to verify the jwt token (using any jwt verification lib)
and then create a new session using the session.createNewSession function
m
aah.... I think the logic you are placing is that both the domains are hosted with their Supertokens NodeJS SDK's, connected with a common Supertokens core backend
r
yup.
m
that way, they will be able to create sessions based on a common JWT
r
yup
m
interesting.
6 Views
PreviousNext
Powered by