GitHub user aglinxinyuan 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. I'm ok to have the password in the new table. I didn't consider the read path. What's the pair for local login in your final design? GitHub link: https://github.com/apache/texera/discussions/6716#discussioncomment-17817979 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
