6. Authentication / Account creation

6.1 Thoughts

When a user wants to subscribe to a feed, she must enter her login and password combination.

If the user does not have a valid account, the account can be automatically created. When loading the email subscription manipulation page, if no user is logged in, a special login screen should appear with an option "create account". On selection of this link, the automatic account creation page should be displayed. On login, the email subscription manipulation page should be displayed, filled with data of this user.

When an account is automatically created, the user in the normal user database is created. The user database can be in the LDAP or in an SQL or in any other kind of database, depending on the permission system in use. In order to keep track of user accounts which have been automatically created, the email_auto_users table is used.

6.2 Specification: Login Form

The file include/loginform.html should be modified so it displays a link to the auto account setup page if the page requested is the email subscription manipulation page email_sub.php3 .

6.3 Specification: Automatic Account Creation page: autocreate.php3

The new file admin/autocreate.php3 contains the mechanism to automatically create a new account.

If called without the confkey argument, a form is displayed where the new user must fill in the following fields:

• login name
• password
• retype password
• email address

The form contains a submit button which makes autocreate.php3 to check the data entered and create the account. Checks should be done for maximum field lengths, minimum field lengths (mandatory field content existence) and the login name may not already exist. If one of these problems occur, an appropriate error message should be displayed and user user should have the chance to correct the form and resubmit.

When everything is fine, several things happen:

• The data is filled into the user storage using the AddUser() function of the permissions library.
• A new record in the email_auto_users table should be created. This record should be filled with the "confirmed" flag set to 0 because we do not yet know if the person who entered the data really can read the email she entered. Also, its confirm_key field is filled with a random string value (probably as returned by the new_id() function).
• An email is sent to the email address entered. The text comes from the common language file, and a link is included which points back to the autocreate.php3 script with a parameters indicating the user name (uid) and the confirmation key (confkey).

When the script is called with the confkey argument, it behaves completely different:

• The argument uid is required.
• A record with a matching uid from the email_auto_users table is selected. If found, the confkey is compared.
• A message is displayed confirming the success or indicating the failure of confirmation.
• On success of confirmation, the confirmed flag of the selected record is set to 1.

6.4 Specification: User admin interface changes

The existing user administration interface, um_uedit.php3, needs a change. Whenever a user's settings are changed, the corresponding record in the email_auto_users table is deleted. This avoids automatic deletion of this user.

6.5 Specification: Automatic cleanup of automatically created user accounts: email_auto_cleanup.php3

After all, we automatically create user accounts. Some of them will never be used (missing confirmation) and some will simply be forgotten.

An automatically created user account is considered to be trash if

• the account has not been confirmed 7 days after creation
• or the account has no subscriptions attached for at least three months.

The new script email_auto_cleanup.php3 is called regulary from the cron-daily.php3 script. It performs the following steps:

• Select all records from the email_auto_users table which have a confirmed value of 0 and a creation_time older than 24 hours
• remember those user ids
• Select all records from the email_auto_users table which have a last_change older than three months and which have no corresponding record in the subscriptions table
• remeber those user ids, too
• delete all remembered users without hesitating from the email_auto_users table and from the user database through the permission system