#Confused about Auth using different providers - same email sign-in is making a difference?

17 messages · Page 1 of 1 (latest)

west horizon
#

I genuinely think this is not a bug!

#

accidently showed my personal data (emails)

#

Explanation:
when I sign-in with github or google using the same email, the information changes, which had me confused

austere pivot
west horizon
velvet sinew
#

@west horizon since I didn't see the original post: I'm assuming after you sign up with the other OAuth provider the accounts are linked and the user information changes. What changed? Which fields do you care about? What is the behavior you want?

west horizon
velvet sinew
#

Everything changed (besides _id and email presumably), and you don't mind it?

drowsy harbor
#

After moving over things more or less worked for me as well, but it may be worth considering having Convex Auth make an authUsers table instead of users.

  • makes migrations smoother due to lower likelihood of collisions
  • allows apps to continue their own pattern of users table, which most apps probably have by that name, and gives freedom to determine how to integrate with convex auth
  • probably simplifies using multiple auth providers, whether during a migration phase, or some apps may just use multiple providers ongoing
#

If Convex Auth had created an authUsers table, I probably would have kept my users table as is and just added an authId field for linking up.

#

And of course, if someone doesn't want all that noise, they can just use the authUsers table directly.

austere pivot
#

I personally am always making my own users table with a custom createOrUpdateUser function. I prefer to not have the default users table, for the above reasons and more.

#

The reasons against a authUsers table in my view:

  1. When there's an auth user but not an entry in your users table, you have the client-driven storeUser useEffect waterfall. <Authenticated> doesn't equate to "I have a user"
  2. Getting a user ID only gives you access to a document you then have to read your "real" user ID from
  3. You have similar issues to the Clerk data split problem - do you keep a name and email address in both your authUsers and users table? Do you keep them in sync somehow?
#

I view the built-in users table as useful for the user you described:

if someone doesn't want all that noise, they can just use the authUsers table directly.
maybe most folks are less opinionated about their users table than me, though. I like to see all "my" tables personally

drowsy harbor
#

Fair points. I do think most of that can be solved with pretty simple convex functions. Even the waterfall issue just requires making my own <Authenticated> that includes a user check. But the current approach is definitely simpler, no doubt.