Improve Logic Design of `signIn` method and allow explicit options
Feature request
It should be possible to disable automatic magic links.
Actually I think the signIn method has a bad architectural design, prove me wrong.
Logic should be split by concerns, but the signIn allows magic link, phone login, password login etc. all by "guessing". This is meant to lead to failure. Instead I'd either expect different methods such as signInByPhone etc. or at least a config flag enforcing the requirements.
Currently what happens is that when I do signIn({email}) it will trigger sending a magic link - even if I want it to be login per password.
Problem description below 👇
Problem Description
Now you guys probably thought of "This is a cool feature and is pretty convenient". In most cases it is. But Architecture Design is all about requirements both technically as well as considering your Personas etc.
Now let me sketch a use-case (I have MANY more if needed):
Use-case 1:
I have a target group that doesn't have immediate access to their E-Mail so-to-speak hence the Magic Link is becoming inconvenient due to the amount of actions needed.
You would probably argue: Then don't use it and use signIn({email, password}) . Well, fair point, however no code is perfect and good Architecture lives by "Design for Failure" so I'm having somewhere a code fail where instead of {email: 'mail...', password: 'pass...'} only the email prop is provided but the password prop is missing/undefined. Rest assured this can happen on library level. Now what? The magic link is sent, the function acts "succesfully" and the code is confused expecting a valid session and so is the user. Especially more confusing since that user isn't expecting a magic link.
Have you looked at v2 yet? https://supabase.com/docs/reference/javascript/next/auth-signinwithpassword https://supabase.com/docs/reference/javascript/next/auth-signinwithotp https://supabase.com/docs/reference/javascript/next/auth-signinwithoauth
So kinda I criticize what's been improved already. So I guess we can close this. Probably didn't notice it because it's not yet deployed in my latest package as it's still RC
But one question remains open: Wouldn't that still leave the problem open of still technically being able to do OTP? I'd like to be able to disable those (but I guess then this would be a supabase ticket, not a gotrue one?)
https://supabase.com/docs/reference/javascript/next/auth-signinwithotp
I think this should be extended to fit your needs:
signInWithOtp({..., shouldCreateUser: true, onCreateUserData: {your_meta_data}})
Hey @activenode, this is now possible in the rc branch for signInWithOtp. Please take a look at https://github.com/supabase/gotrue-js/blob/rc/src/lib/types.ts#L313-L320 - we'll file a separate PR to update the docs on the site to reflect this change.
You guys are the best!.
Not sure if this needs a separate issue, but are there plans to extend this functionality out to SignInWithOAuthCredentials / signInWithOAuth? I'd like to be able to offer users the ability to OAuth once they've been invited to the App but without allowing them to create an account automatically. I believe this used to be supported under v1.0.