View Issue Details

IDProjectCategoryView StatusLast Update
0000177WackoWikiactionpublic2009-08-19 09:39
Reporteradministrator Assigned ToTann San  
Status resolvedResolutionfixed 
Product Version4.2 
Target Version4.3.rcFixed in Version4.3.rc 
Summary0000177: Registration: add case "EmailAlreadyConfirmed" -> check for empty email_confirm field
DescriptionACTION registration

now if someone click the confirming Link for some reasons twice he got also the message "EmailNotConfirmed" instead that his email is already confirmed - confusing for the user who got this for his case wrong message
TagsNo tags attached.


Tann San

2008-06-09 21:46

manager   ~0000359

I had a look at this tonight. I think the only thing we need to do is change the feedback message. At the moment it states:

"Email cannot be confirmed. Maybe wrong code?"

We can just change that to say:

"Email cannot be confirmed. This may be due to an incorrect confirmation code or the email address may already be confirmed."

The problem we have with confirming email addresses is that on the registration page we only take a "confirm" id like so:


We have nothing else to go on to identify the account we're trying to confirm. We can't assume it's the currently logged in account since Admin users can register other users.

We could have an input field on that page like "Enter email to check: " but that then means someone could sit there and brute force the system trying to find valid email addresses of the users.

My Suggested Fix (that I won't implement until we agree on it)
What we could do with is a tick or cross next to the users email address in their settings page. The tool tip for it can state "Confirmed" and "Not Confirmed". So that along with changing the current error message to:

"Email cannot be confirmed. This may be due to an incorrect confirmation code or the email address may already be confirmed. You can check if the email address is already confirmed by logging in and viewing its status on your [[Settings Settings]] page."


2008-06-11 20:38

administrator   ~0000364

why we couldn't just look up in the table and if the field is empty, we say email is already confirmed else other case it's a more precise answer

Tann San

2008-06-11 21:16

manager   ~0000365

Because we have nothing to look up. Oki so I need to explain this better.

  * New user registers.
  * Their row in the Users table gets a guid entered into the EmailConfirmed row.
  * System sends them an email with a link, at the end of the link we add the guid generated in the last step.
  * User visits that link
  * System checks their guid against the one in that column and if theres a match it clears the column and shows them the "Thanks for confirming" message.

The select statement for that last part is like "select id from users_table where EmailConfirmed = guid". The point here is that the only thing we have to go on is the guid.

When the guid cannot be found via the select statement it can mean one of two things has happened:

1) The user is a valid user and they have already confirmed their email.
2) It's someone testing out different guids for some naughty ends.

Either way if the select statement comes back with no results it doesn't tell us whether a row existed or not.

I think what I suggested last time is a good and easy to implement solution.


2008-06-11 21:42

administrator   ~0000366


Tann San

2008-06-16 15:37

manager   ~0000372

Changed error message to cover multiple scenerios. Also added a tick or warning sign next the email address on the User Settings page.

Issue History

Date Modified Username Field Change
2008-06-04 03:26 administrator New Issue
2008-06-04 03:26 administrator Legacy => NEW
2008-06-04 03:27 administrator Status new => confirmed
2008-06-09 21:46 Tann San Note Added: 0000359
2008-06-09 21:46 Tann San Status confirmed => assigned
2008-06-09 21:46 Tann San Assigned To => Tann San
2008-06-11 20:38 administrator Note Added: 0000364
2008-06-11 21:16 Tann San Note Added: 0000365
2008-06-11 21:42 administrator Note Added: 0000366
2008-06-16 15:37 Tann San Status assigned => resolved
2008-06-16 15:37 Tann San Fixed in Version => 5.0.0
2008-06-16 15:37 Tann San Resolution open => fixed
2008-06-16 15:37 Tann San Note Added: 0000372
2009-08-19 09:22 administrator Fixed in Version 5.0.0 => 4.3.rc
2009-08-19 09:39 administrator Target Version 5.0.0 => 4.3.rc
2010-03-08 10:09 administrator Category Action => action