Issues with EmailVerification
|Reported by:||izzy||Owned by:||hasienda|
|Severity:||normal||Keywords:||user register verify email|
I just updated one of my Trac installations (from Trac 0.11 to v1.0, AccountManager 0.2.1dev + EmailVerification patch from ticket:5509 to v0.4.3). While everything seems to work fine so far, I've noticed some issues concerning EmailVerification. Let me first list the processing steps, so I can address the issues better:
- User "Joe" visits the /register link, fills the form (including EMail), and submits it
- Mail is sent to the Trac Admin ("New user created"), user is informed (on page) to log in
- Joe logs in for the first time
- Joe is re-directed to the profile (to complete other data), while the verification mail is sent in background. A corresponding information is displayed on the page.
No issue with step 1. But at the point of step 2, first problem arises: if Admin checks the account of Joe on the WebUI, it says there the email address had been verified successfully – which is simply wrong and misleading, as the verification mail had not even been sent. Which means the Admin has no way to tell which accounts are really "verified". This is especially bad when your site has many bots visiting, which simply register and never come back (I encounter that frequently).
Next issue comes in at step 4: "A mail was sent to to verify your new address". You see, the mail address itself is missing there ("to to"), though it's used correctly in the mail sent (this part might be related to what's described in ticket:10215 – but as that was closed more than a year ago, it could be something else as well).
For a solution to the first issue, may I suggest to adjust the "workflow" a little towards how it had been back with the mentioned patch? I would very much welcome to have the verification mail sent right on submit of the registration form (at least optionally/configurable, but I wouldn't mind at all if that were mandatory). This would show the account as "unverified" in the admin WebUI immediately, as the fields email_verification_sent_to and email_verification_token are set right from the start. I fully understand the advantages of the current model (even accounts created before AccountManager was activated will be verified on the next login), but that check could still remain intact (affected accounts have no email_verification_sent_to set, so they could be identified based on this fact).
Even if another path is chosen: I guess to have this as "mandatory" wouldn't require much more than one or two lines of code added somewhere in register.py. I would really appreciate to know this code so I could patch it in my installation, as I require this order of processing for multiple other reasons as well (beside the WebUI, I also use cron jobs identifying unverified accounts this way, amongst other things).