[pmwiki-users] A robust user registration module

[Eemeli Aro]

On 24 May 2010 13:59, Wordit Ltd <wordituk at googlemail.com> wrote:
> I just realised this a lot simpler than I thought. There is no need
> for temporarily storing the sign-up info.
>
> I think this should work:
>
> - user supplies email, username, password via a form
>
> - create a key containing supplied info plus a secret: sha1($email.).
>
> - Mail to user. No record is kept because the key can be generated
> from info the returning user enters plus the secret.
>
> - user goes to verification page and enters the info plus the key. The
> key is checked.
>
> - if it matches, append, replace, or remove entry in wiki page
>
> The only general functions needed are to find a line in a wiki page,
> and write to a page. (I guess both these already exist as pmwiki
> functions?)

One of the most useful things you can do with a verified e-mail
address that's linked to a user account is to use it to reset a
password. With the above method, where is the email address kept? If
you immediately forget the e-mail address, why do you verify it in the
first place?

Requiring the user to enter their email address once before and then
again after activation seems silly. What's the harm in keeping the
info on the server if it makes a user's first experience with the site
easier?

If two users both want to register the same username, the one that
first activates it gets it, rather than the one that first requests
it, which is a more common way of doing it.

Requiring an admin to come up with a secret for the hash adds extra
work that isn't necessary, and you can't set any default values for
it. For both the user and the admin, it's easier if the information is
kept on the server, and the key to be a randomly generated string that
can be matched to the information.

Is the number of non-activated accounts really going to be big enough
that you need to care about them polluting the namespace? To weed out
spammers, a captcha and a honeypot field should be sufficient.

If you don't care about keeping the email address, or if you want to
put it somewhere less accessible like the page change summary, I'd
implement this as follows:
  1. Get $username, $password, $email from user + validate them
  2. Generate $hash from $password
  3. Generete $key from random number generator
  4. Set $ChangeSummary to something like "added $username <$email>"
  5. Add a line to SiteAdmin.AuthUser:
      #$key $username: $hash
  6. Send $key to user as activation link in an email
  7. Tell user to click on activation link
  8. On activation, find the line matching the key
  9. Remove "#$key " from the beginning of the line
  10. Done.

Now, most of the work will go into the framework for doing all that
along with the input validation. The code for actually reading &
writing pages is actually a small part of the whole. For a practical
example of this, see the code I added yesterday to
<http://www.pmwiki.org/wiki/Cookbook/AuthUserProfiles> which uses
profile page attributes to keep the data.

eemeli