GitHub user Neilk1021 added a comment to the discussion: Proposal - Migrating User Authentication to a new table to support multiple log-in sources.
> The password should remain in the `user` table. Why does it need to be stored > in this table? While allowing `NULL` values is inexpensive, that's not a > sufficient reason to move it here. Fair pushback. The case for moving the password is the code path, not storage. If the hash stays on users, local auth is permanently a special case: one branch reads users, another reads auth_provider, and every new strategy has to pick a side. Additionally a SELECT * on a profile endpoint can't leak credential material, and the credential table can be locked down separately. Worth noting your example table above already had local | hash64e2f2f2f24f2f as a row, so I think we're closer than it reads. The real crux is whether local is a provider or the absence of one. Django/Devise do keep passwords on the user model, so that position isn't arbitrary, but I just think uniformity wins here. > `google_avatar` is unrelated to this discussion. Let's handle it separately. To clarify, I'm not moving it, just renaming in place on users. It's two lines in the same migration and we're already altering that table, so folding it in avoids a second pass. Happy to split if you'd rather, but its not a semantic change. GitHub link: https://github.com/apache/texera/discussions/6716#discussioncomment-17816614 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
