user registration design

Question

I am building a custom user registration/login/ bla bla bla library for code igniter.

I am looking for some hints as to what direction to take for the library.

I.E obviously as well as the general library file you are going to need some other functions that call the library.

Where should validation logic go?

Scenario

we make a request to http://example.com/user/register/joe@mail.com/joesPassword

Now at some stage the register function in the user controller needs to call the register function in the user library.

Do I build the validation (already exists, password required, email valid, password meets minimum criteria etc) into the controller or the library.

My initial instinct is to build the validation into the controller and leave the library functions to do only one thing. I.e the register function in the user library would simply sha1() the password and insert the username/password into the database.

Am I going along the right track here, or should the library do all the work and the controller simply act to receive and pass on the request?

Answer 1

I assume you're doing this for your own benefit, i.e. for purely self-educational purposes. If not, you are probably reinventing the wheel - I can hardly imagine that codeigniter doesn't have a fully fledged registration solution yet. Nonetheless, if you really want to build a library handling user registration, please consider the followings:

• Don't pass registration form parameters as part of the URL. http://example.com/user/register/joe@mail.com/joesPassword is clearly a bad example and a huge security hole. Use "post" method for your form to pass variables to your controller.
• Use client side validation, preferably with an out-of-the-box javascript solution built on jquery, mootools, yui, etc - whatever is your js library preference. Using client side validation saves time and frustration for your future users. Check for username availability, password strength, email address validity (via regexp), password matching for the confirm password field. Client side validation belongs to the "view" part of your library.
• Use a hashed site secret as hidden input in your form.
• Use an accessible captcha for your form.
• Make your forms sticky, based on session. If your user fills in the form, navigates away before completing the registration, and comes back to the form, he/she should be presented with the previously filled values.
• Enable 3rd party registration. Users should be able to register to your site via their 3rd party accounts - enable openID and facebook connect as a bare minimum on your registration form
• Use server side validation, check for all field contents validity, escape all user inputs. Server side validation belongs to either the controller or the model part of your library, I'd prefer to put it into the model.
• Create configurable workflow. If you're trying to create a flexible library, you'll have to accommodate various needs for the registration workflow. Some of your library users will want to have manual account review before enabling a user on their site. Others will want to auto-enable users once they confirmed their request via email.
• Do not hardcode what fields are part of the registration form. As a rule of thumb, the less is more when it comes to registration, so you'll want to have the bare minimum set of fields when registering users (otherwise they'll just say, "haha you're asking for my mother's maiden name? no thank you"). However, you're building a library, so let your library users decide what fields will be included on the registration form
• As an addendum to the previous point, create a flexible API for defining registration form fields, types and validation rules.

I'm sure there are a lot more guidlines, I haven't mentioned custom views for mobile devices and probably a lot more. But the above should give you a start towards the right direction.

And as for this part of your question: "Am I going along the right track here, or should the library do all the work and the controller simply act to receive and pass on the request?" - this is a matter of preference IMO, but I'd use the controller as doing general tasks, i.e parsing form values and escaping them, and pass those preprocessed values to the model where the actual (semantic) validation takes place.