Page 1 of 1
Modelling users and user profiles
Posted: Thu Jun 05, 2008 2:13 pm
by matthijs
In general terms, how do you handle user registration and user profiles in your web apps nowadays? let's say you're building the next community site in which people can register for an account, log in, manage and share their widgets etc
It's a complicated subject, but I'd still like to hear your opinions on a few questions:
- do you use an email confirmation system in which a confirmation link is sent to the useres' email? Certainly considering the spambots nowadays, my guess is that it's a lost battle if I would not use such a system. Captcha's are a last resort to stop the bots, not something I'd like to implement.
- do you generate passwords or do you let people pick their own password?
- do you have separate tables in the db for the main user data (username, email, password) and user profile data (real name, birthdate, favorite pets, etc)? I ask this because in many apps, what you want to store might and probably will change in the future. So having separate tables seems like a good solution. In the user_profile table you could even use generic field-value columns, so that you can store as much info for each user as you (or the user) wants. Maybe querying that table takes more processing time, but the flexibility is huge.
There's many more questions I have, but these are the main ones I have at this moment.
Re: Modelling users and user profiles
Posted: Thu Jun 05, 2008 2:36 pm
by Benjamin
matthijs wrote:
- do you use an email confirmation system in which a confirmation link is sent to the useres' email? Certainly considering the spambots nowadays, my guess is that it's a lost battle if I would not use such a system. Captcha's are a last resort to stop the bots, not something I'd like to implement.
I allow the user to pick their own password. I then send the user an activation code. The user must then log in with the activation code and the password. The password is not sent to the email address to ensure that the person who receives the email is the same person who registered.
matthijs wrote:
- do you generate passwords or do you let people pick their own password?
See above.
matthijs wrote:
- do you have separate tables in the db for the main user data (username, email, password) and user profile data (real name, birthdate, favorite pets, etc)? I ask this because in many apps, what you want to store might and probably will change in the future. So having separate tables seems like a good solution. In the user_profile table you could even use generic field-value columns, so that you can store as much info for each user as you (or the user) wants. Maybe querying that table takes more processing time, but the flexibility is huge.
The most common data would be placed into the members table, with subsets of categorized data in separate tables. For example, member_id, username, password, last_login, age etc would go in the main table. I would place things like resumes, demographics, profile data etc in secondary tables which can be easily joined on the member_id key. Especially any big fields that aren't used often.
Re: Modelling users and user profiles
Posted: Fri Jun 06, 2008 1:05 am
by matthijs
astions wrote:I allow the user to pick their own password. I then send the user an activation code. The user must then log in with the activation code and the password. The password is not sent to the email address to ensure that the person who receives the email is the same person who registered.
Ok, thanks. Sounds like a good approach. There's so many ways to do this, and what's friendly for a user might be less secure and vise versa.
Then in the registration form it's probably a good idea to have a second field for the password (confirm password) to make sure the user doesn't accidentally mistypes his password, isn't it?
astions wrote:The most common data would be placed into the members table, with subsets of categorized data in separate tables. For example, member_id, username, password, last_login, age etc would go in the main table. I would place things like resumes, demographics, profile data etc in secondary tables which can be easily joined on the member_id key. Especially any big fields that aren't used often.
Ok, thanks for you input. Sounds good.
Re: Modelling users and user profiles
Posted: Fri Jun 06, 2008 9:12 am
by Maugrim_The_Reaper
If allowing users to choose their own password, I'd also add an optional javascript class to check it's strength - make them feel guilty for using something really stupid

. It's a tiny addition but encourages stronger passwords.
Otherwise pretty much what astions said. Nice touch requiring both code and password at the same time for the confirmation.
On CAPTCHAs, I've started to use reCAPTCHA as a general solution. It's nice, easy to implement, has a secure API, and it supports a built in non-visual option. It's the only CAPTCHA I've ever recommended since I know developers with accessibility problems so I only use a CAPTCHA when every other conceivable option has failed.
Re: Modelling users and user profiles
Posted: Fri Jun 06, 2008 9:21 am
by matthijs
Ok, that's good advice as well, thanks.
About the activation code: from a security point, it's basically the same as sending someone a confirmation link they have to click before being able to login with their username and password isn't it?