<p>Just answering this for anyone else who sees this. The case above was confirmed by Brad Bell and was fixed in <a href="https://craftcms.com/changelog#2-6-2984" rel="nofollow noreferrer">Craft 2.6.2984</a>. So, going forward, the scenario described above should return an error to handle.</p>

CC BY-SA 3.0
2017-07-21T22:05:29.553Z
2017-07-21T22:15:47.293Z
2017-07-21T22:15:47.293Z
Mike
<p>We have a front end form for a logged in user to change their Username (email). In our testing, it does not appear to check against and prevent selecting an email address that's already taken (like happens on a login form). However, our Create Account from - which is almost identical - works.</p>

<p>This Form (our create account form) works and catches duplicate emails and returns an error:</p>

<pre><code>&lt;form id="createForm" method="post" accept-charset="UTF-8"&gt;

    {{ getCsrfInput() }}
    &lt;input type="hidden" name="action" value="users/saveUser"&gt;
    &lt;input type="hidden" name="redirect" value="{{ siteUrl }}account/signup-sent"&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Email &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
        &lt;input id="signupEmail" name="email" placeholder="Email" value="" data-parsley-type="email"&gt;
    &lt;/div&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Confirm Email &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
        &lt;input id="confirmEmail" placeholder="Confirm Email" value="" data-parsley-type="email"&gt;
    &lt;/div&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
        &lt;input name="password" id="password" type="password" placeholder="Password" value=""&gt;
    &lt;/div&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Confirm Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
        &lt;input name="confirmPassword" id="confirmPassword" type="password" placeholder="Confirm Password" value=""&gt;
    &lt;/div&gt;
    &lt;input type="hidden" name="fields[accountReceiveEmails]" value=""&gt;
    &lt;div class="checkbox"&gt;
        &lt;input type="checkbox" name="fields[accountReceiveEmails][]" value="yes" id="emailOptin"&gt;
        &lt;label for="emailOptin"&gt;&lt;span class="checkbox"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;Yes, I would also like to receive offers, discounts and news for Cadex products by email.&lt;/label&gt;
    &lt;/div&gt;
    &lt;footer&gt;
        &lt;button&gt;Create Account&lt;/button&gt;
    &lt;/footer&gt;
&lt;/form&gt;
</code></pre>

<p>This is our form for users logged into their account. It does not return an error when a user tries changing their email to one that already exists in another account:</p>

<pre><code>&lt;form id="profileCredsForm" method="post" accept-charset="UTF-8"&gt;
    {{ getCsrfInput() }}
    &lt;input type="hidden" name="action" value="users/saveUser"&gt;
    &lt;input type="hidden" name="redirect" value="account/profile/saved"&gt;
    &lt;input type="hidden" name="userId" value="{{ currentUser.id }}"&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Current Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
        &lt;input id="currentPassword" name="password" placeholder="Current Password" value="" data-parsley-required="true"&gt;
    &lt;/div&gt;

    &lt;div class="input"&gt;
        &lt;label&gt;New Password&lt;/label&gt;
        &lt;input name="newPassword" id="newPassword" type="password" placeholder="New Password" value=""&gt;
    &lt;/div&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Confirm New Password&lt;/label&gt;
        &lt;input name="confirmNewPassword" id="confirmNewPassword" type="password" placeholder="Confirm New Password" value=""&gt;
    &lt;/div&gt;

    &lt;div class="input"&gt;
        &lt;label&gt;New Email&lt;/label&gt;
        &lt;input id="email" name="email" placeholder="New Email" value=""&gt;
    &lt;/div&gt;
    &lt;div class="input"&gt;
        &lt;label&gt;Confirm New Email&lt;/label&gt;
        &lt;input id="confirmNewEmail" placeholder="Confirm New Email" value=""&gt;
    &lt;/div&gt;

    &lt;button type="submit"&gt;Update&lt;/button&gt;
&lt;/form&gt;
</code></pre>

<p>We've tested this repeatedly, changing an email to one for another existing account and no error is returned, the form submits and the email is sent to confirm the new email address.</p>

<p>Also, as an aside, the confirm link in the follow up email seens to ignore the <code>activateAccountSuccessPath</code> set in our config. Is that expected behaviour?</p>

<p>Thanks.</p>

CC BY-SA 3.0
2017-06-15T23:02:32.187Z
You're saying you've got one form where it works as expected and an identical form where it doesn't?
Brad Bell
CC BY-SA 3.0
2017-06-15T23:21:10.323Z
I've expanded the original post with both forms. While not literally identical, I cannot see any functional difference between them that would affect this behaviour (if, indeed, logged in users should be prevented from updating their email (username) to one that already exists). FYI, twig error code and client side validation has been removed for clarity.
Mike
CC BY-SA 3.0
2017-06-15T23:58:08.777Z
As far as Craft is concerned, the first is going to register a new user and the latter is going to edit an existing user.  But I just did a test case with your 2nd form and changed the email to another existing email address and got the expected "Email "a@b.com" has already been taken." validation error.
Brad Bell
CC BY-SA 3.0
2017-06-16T00:02:12.097Z
Wow... ok, thanks Brad. Not certain what is going on then. We have Commerce installed also but I assume that should have no affect, correct?
Mike
CC BY-SA 3.0
2017-06-16T00:05:56.877Z
Wouldn't think so... if you've got xdebug.org installed, throw a breakpoint in Craft's `craft/app/controllers/UsersController->actionSaveUser()` and that might shed some light on what's going on.
Brad Bell
CC BY-SA 3.0
2017-06-16T00:13:43.433Z
Ok... and just curious. Should the verify email link in this scenario bypass a `activateAccountSuccessPath`?
Mike
CC BY-SA 3.0
2017-06-16T01:40:10.813Z
Not at computer, but I'd guess so? The account is already activated for an existing user, you're just verifying the email.
Brad Bell
CC BY-SA 3.0
2017-06-16T03:31:15.573Z
Thanks Brad. Can we pursue this further through another channel? I have been able to reproduce this behaviour consistently on a new, clean install of Craft in a new environment with absolutely barebones forms. I'm guessing your test had one of two things different.
Mike
CC BY-SA 3.0
2017-06-16T18:40:15.927Z
Can send a database dump, templates and steps to reproduce over to support@craftcms.com and we can try it there.
Brad Bell
CC BY-SA 3.0
2017-06-19T18:11:33.933Z
Just totally throwing this out there, but Craft has elevated sessions to that if you change an email or username, Craft will ask for the currently logged in users' password to confirm the change. Perhaps since it  isn't getting that, its skipping everything and sending the verify email anyway?
Damon
<users>
Changing Username On Front End To Another Account Email
# Changing Username On Front End To Another Account Email

(Asked by: username_0 on 2017-06-15)

We have a front end form for a logged in user to change their Username (email). In our testing, it does not appear to check against and prevent selecting an email address that's already taken (like happens on a login form). However, our Create Account from - which is almost identical - works.
This Form (our create account form) works and catches duplicate emails and returns an error:


    {{ getCsrfInput() }}
    
    
    
        Email *
        
    
    
        Confirm Email *
        
    
    
        Password *
        
    
    
        Confirm Password *
        
    
    
    
        
        Yes, I would also like to receive offers, discounts and news for Cadex products by email.
    
    
        Create Account
    


This is our form for users logged into their account. It does not return an error when a user tries changing their email to one that already exists in another account:

    {{ getCsrfInput() }}
    
    
    
    
        Current Password *
        
    

    
        New Password
        
    
    
        Confirm New Password
        
    

    
        New Email
        
    
    
        Confirm New Email
        
    

    Update


We've tested this repeatedly, changing an email to one for another existing account and no error is returned, the form submits and the email is sent to confirm the new email address.
Also, as an aside, the confirm link in the follow up email seens to ignore the activateAccountSuccessPath set in our config. Is that expected behaviour?
Thanks.

**Tags:** users

> **Comments:**
> **username_1**: You're saying you've got one form where it works as expected and an identical form where it doesn't?  
> **username_0**: I've expanded the original post with both forms. While not literally identical, I cannot see any functional difference between them that would affect this behaviour (if, indeed, logged in users should be prevented from updating their email (username) to one that already exists). FYI, twig error code and client side validation has been removed for clarity.  
> **username_1**: As far as Craft is concerned, the first is going to register a new user and the latter is going to edit an existing user.  But I just did a test case with your 2nd form and changed the email to another existing email address and got the expected "Email "a@b.com" has already been taken." validation error.  
> **username_0**: Wow... ok, thanks Brad. Not certain what is going on then. We have Commerce installed also but I assume that should have no affect, correct?  
> **username_1**: Wouldn't think so... if you've got xdebug.org installed, throw a breakpoint in Craft's `craft/app/controllers/UsersController->actionSaveUser()` and that might shed some light on what's going on.  
> **username_0**: Ok... and just curious. Should the verify email link in this scenario bypass a `activateAccountSuccessPath`?  
> **username_1**: Not at computer, but I'd guess so? The account is already activated for an existing user, you're just verifying the email.  
> **username_0**: Thanks Brad. Can we pursue this further through another channel? I have been able to reproduce this behaviour consistently on a new, clean install of Craft in a new environment with absolutely barebones forms. I'm guessing your test had one of two things different.  
> **username_1**: Can send a database dump, templates and steps to reproduce over to support@craftcms.com and we can try it there.  
> **username_2**: Just totally throwing this out there, but Craft has elevated sessions to that if you change an email or username, Craft will ask for the currently logged in users' password to confirm the change. Perhaps since it  isn't getting that, its skipping everything and sending the verify email anyway?  

---

## 1 answers

### Answer by username_0 on 2017-07-21. Score: 1

Just answering this for anyone else who sees this. The case above was confirmed by username_1 and was fixed in [Craft 2.6.2984](https://craftcms.com/changelog#2-6-2984). So, going forward, the scenario described above should return an error to handle.


---

