Depending on the type of website you are building, your user registration needs could vary greatly. You might have a private, friends-only Vanilla installation. You might have a corporate, local-network installation that requires a no-frills setup. You might be a very public site where you need a bot-checker or even human-checking of applicants. Garden covers all of these methods and more. There are five methods for registration that are included in Garden out of the box.
Closed
Simply put, registration is closed. Going to Garden’s registration screen tells you just that. Administrators can then add users manually (and send out welcome emails as they are created) using the user administration screens.
Basic Registration
No frills user registration. Users are prompted to enter their username, email, password, and are granted access immediately after submitting the form.
Captcha
Using the free recaptcha.net service, this option allows you to add a captcha anti-bot tool to prove that the person applying is, in fact, a person. Assuming that the user sufficiently proves this, they will be granted access immediately after submitting the form.
Approval
Administrative approval is my personally preferred method for granting users access to your site. With this method, after registration, users are added to an “Applicants” list that administrators can then review and choose to approve or deny access. A little slower than most registration methods, but far less prone to allowing bad seeds into your user base.
Invitation
Users are granted a pre-defined number of invitations-per-month which they can send out to friends and colleagues. The only way new members can get into the system is by receiving one of these invitations. The system keeps track of who invited who (and I can only imagine the fun that someone might have creating a plugin to map out the family tree of a user base created in this way).
Session Handshakes
With Vanilla 1 I tried to adopt a newfangled method of integrating user tables between applications so that, for example, a wordpress installation could use vanilla’s user table or vice versa. In the end, this method was neat, but difficult to implement. Not to mention that it required that the user tables from both applications be in the same data source. What if the other app’s db was in postgre? What if it you wanted to use some other type of authentication altogether that had nothing to do with databases?
In Garden I’ve taken a much simpler approach to user registration/integration. In order to integrate Garden’s user table with any other application, all you would need to do is write a session handshake function, and create a plugin to fire before Garden’s session starts. In the session handshake function, you can validate that the request is from a trusted source using whatever method you desire, and then give it a username to create. The user will be created if it doesn’t exist, or the user will be authenticated otherwise. By the time Garden gets to loading it’s own session, the user has already been authenticated (and possibly even created if it hadn’t exited in the Garden database before) and signed in. The user should seamlessly be coasting through Garden pages without even knowing they were registered.
