Replies: 1 comment
-
I came across the same situation today. Here is a bit about my scenario: However, I soon realised that the
I'm wondering if there is an alternative approach for my scenario. Just getting the session back would have been nice. While the email is being sent, I get:
|
Beta Was this translation helpful? Give feedback.
-
Hi all,
I have a use case where there are some type of users I did not want to sign up at all. My initial assumption was that with OTP I would be able to create a temporary session for a given user without the need of signing the user up, thinking that a session would be created it would be authenticated and be able to take few actions on the platform. When I went into details to implement it I realized that it is not the case and the user always gets signed up.
My next assumption when preparing the middleware to protect some routes was that, as when you
signUp()
a user you get aSession
object as a response, I was expecting to get back aSession
object fromsignInWithOtp()
(hoping to distinguish when to allow access to the OTP sign in and when to allow access to the verification route based on if there is a session or not and if there is a session but without a user yet until the verification happens), but again I was wrong in my assumption and reading the GoTrueClient, in all of the cases the return isreturn { data: { user: null, session: null, messageId: data?.message_id }, error }
So:
Session
when signing up but not when signing in using OTP (which also signs up the user if not existing)? Any plans to return aSession
instead pending to be verified with the OTP and then adding theUser
object tosession.user
?Thanks!
Beta Was this translation helpful? Give feedback.
All reactions