[eluser]davidbehler[/eluser]
Quote:What happens if for example one auth library purely wanted to focus on email login and had no use for user_name.
Quote:If the application needs more user data then a application specific user table is created linking to the standard users field(s).
Guess that answers your question. Whenever an application needs a field that's not in the standard table it creates a new table that linked to the standard one and that holds the additional fields.
I really like that idea and hope that quite some people will work on this!
My proposal for a user table layout looks like this:
Table name: user
Fields:
- user_id PK, INT or BIGINT, auto increment
- user_name VARCHAR(30)
- user_pass VARCHAR(32) (for storing md5 hash of user password, could be extended to VARCHAR(40) for sha1 hash)
- user_salt VARCHAR(32) (for storing md5 hash of salt, , could be extended to VARCHAR(40) for sha1 hash)
I think salting passwords is courteous when saving login data and should be part of the standard.
Additional fields I would like to see are user_email, user_date_last_login and user_is_active but I can see why not everyone would want them in the standard.
Another thing we would have to standardize is naming conventions for tables and columns!
