Why is email added again on emailVerificationCodeTable? It breaks database normalization form.

[deadcoder0904]

The database structure at https://v3.lucia-auth.com/guides/email-and-password/email-verification-codes is like:

export const emailVerificationCodeTable = sqliteTable(
  'email_verification_code',
  {
    id: text('id').primaryKey(),
    code: text('code'),
    userId: text('user_id')
      .notNull()
      .references(() => userTable.id),
    email: text('email')
      .notNull()
      .references(() => userTable.email),
    expiresAt: integer('expires_at'),
  }
)

Why is email added even though user_id is still there that I can do join & get the email if I wanted too? The email has to be kept tracked in 2 locations this way and it breaks the database normalization form. Either 1nf, 2nf or 3nf idk. I'm not a database expert.

But this isn't need at all. Am I wrong?

[pilcrowonpaper]

It limits the token to a single email. This makes sure someone can't register a valid email, change it to an invalid one, and verify their email. I guess you could also delete all user tokens when they change their email, but it's an extra safety measure

[pilcrowonpaper]

yeah no issue, though you may want to write a comment just in case you add that feature in the future

[deadcoder0904]

It limits the token to a single email. This makes sure someone can't register a valid email, change it to an invalid one, and verify their email. I guess you could also delete all user tokens when they change their email, but it's an extra safety measure

bdw how would that work on an email/password login scenario? i honestly don't get it. how would someone change their email to invalid one before signup/login? they can only change it after login.

login -> change email -> update email in 1 place (if we dont add email field at all in token table) -> logout

i dont think there would be any problem at all. can you present me a scenario of what you are saying?

[deadcoder0904]

yeah no issue, though you may want to write a comment just in case you add that feature in the future

naah, its a one & done app like gumroad. people pay. only those who pay have their emails stored in database. only the people who bought can login. no email updating or password at all. just changing from verification links to tokens.

bdw, v3 is much simpler than v2. thanks for that. i love the TimeSpan package to set cookies. setting maxAge was phenomenally difficult.

[pilcrowonpaper]

You'd have to implement the feature, but someone might've mistyped their email when signing up and want to change their email

[deadcoder0904]

damn, i didnt think that at all. i'll probably update the database manually for now. thanks.