Modelling users and user profiles

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Modelling users and user profiles

Post 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.
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Re: Modelling users and user profiles

Post 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.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: Modelling users and user profiles

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Re: Modelling users and user profiles

Post 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.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: Modelling users and user profiles

Post 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?
Post Reply