|Version 4 (modified by 12 years ago) ( diff ),|
This proposal is about adding an email validation facility to Trac.
User enters a new or changes an existing email address in the general preferences tab. Under both circumstances, a verification email must be sent to the user containing a link that will validate the email address to the system, so that the change will come into effect.
But the general preferences tab is not the only place where user's might enter an email address. Similar input fields exist in the ticket system where one can add email addresses for ticket change notification. Other such notifications might exist, given the wide range of plugins making use of the notification subsystem.
Since this is heavily related to the notification subsystem it seems only natural to extend that subsystem with the ability to send email verification mails and in turn receiving notification from the user upon clicking on the verification link. In the general preferences tab a notification must be shown that the email address still needs validation and also a resend email verification mail button must be present.
The notification email clearly needs to be localized/translated.
Consider Email Validation and Other Related Tickets
While the proposal in #9900 can only be used for a quick validation of the user's input, it must also be extended to accommodate situations where one has defined a default domain in trac.ini for sending the email messages to. In addition, the user must be send an email for verifying that it is both a valid email address and also owned by the user entering it.
Proposed Solution / Implementation
The notification API can be extended by for example a send_verification_mail() and for receiving user input, the same subsystem can install a request handler for this, say /verify/email or something like that.
It is still to be defined whether the notification subsystem can access the session information from users who do not have a session with the service, e.g. one enters his or her email in the general preferences tab, then saves the session, upon which a notification mail will be send to the specified email address. Now the user closes the session and also removes any cookies for the site. Then she opens up her email client and sees the mail, clicks on the verification link and…
A provable solution to that problem would be to add another entry to the current user's session, for example the validation hash, which might be based on the email address which is going to be verified by the notification subsystem. This hash is then included with the mail, and, upon returning to the site, via the link provided in the verification mail, the notification subsystem's request handler will look for a validation-hash key in the database which has the same value. If it finds it, it will remove it and the email is then considered verified and valid. If it does not find a valid key, it will redirect to an error page stating that the link was expired.
The same validation-hash entry in the session will be used by the preferences subsystem to display the aforementioned resend validation email, and also the notice that the email address was not validated before.
In case that the sending of the email fails due to the reason that the user is unknown to the foreign system, or relaying is not allowed or other similar errors at the SMTP level, the hash should be invalidated, so that the general preferences tab can report this to the user, for example by stating that the email address is invalid and a different address needs to be entered.
A quick proposal for the changes made to the NotificationApi would be:
- callers must first check this whether email_address_verification is enabled. if it is not they must refrain from calling any of the methods below
- creates a hash used for email address validation
- this would initiate a first lookup of the email address, using an SMTP protocol implementation which can be used by callers to pre-validate the address prior sending the verification email
- sends a verification email to the specified address
- in both cases, the notification subsystem will lookup the email hash in the database prior to connecting to the remote or local system
- it will also lookup the hash for the email address and also will look for whether it was invalidated before, e.g. keys in current user's session validation-hash:<hash-value> as long as the email was not validated, and invalid-email:<hash-value> if it was rendered invalid, and optionally also valid-email:<hash-value>.
- once an email address was invalidated, it will remain in the system for as long as the session is valid, after that, users can again try to use that email address.
- email verification should be made configurable in the TracIni [notification] section, for example using a key enable_address_verification = True|False