Currently a valid email address can be registered as username without any ownership verification. This leads to a multitude of problems including consistency/uniqueness and spoofing.

#111317-83: Allow users to login using either their username OR their e-mail address:

At a minimum, I think we need validation when new users register that their username matches neither an existing username nor an existing e-mail address.

While a bit better than the status quo, this doesn't cut it leading to - em, sorry - superficial fixes like the proposal in #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account which introduces code bloat and new privacy problems, while still not solving the fundamental problems.

It neither is enough to check usernames for uniqueness upon account creation nor upon changing the account name.
Registering with a username that could be an email address always comes with a risk of identity fraud or blockade, if the potential email address isn't verified.

Imagine someone registering with the username 'bill.gates@microsoft.com' or 'dries.buytaert@drupal.org' with her real email address given as 'spoof@xxxhost.ru'.
Regarding the identity fraud case: Bill Gates might not be registered on our site yet, so the address is allowed. Still the fake Bill could post in the name of Bill Gates, and even with a (misleading) sign of being verified.
Regarding the blockade case: Bill Gates might not be registered on our site yet, so the address is allowed. But if tomorrow Bill Gates wants to register as 'Bill Gates' with his email address 'bill.gates@microsoft.com', he will be disallowed to do that because someone else fraudulently blocked Bill's real email address from being registered. Now Bill doesn't only have to live with the fact that there's someone else posting spam in his own name, but he can't even prove that the email address in reality belongs to him.

So what could be our options?

1: The most rigid solution:
Disallow @ signs in usernames.
2: The minimum solution:
Check for existence when registering but give the email address precedence to the username. So, if someone proves to be owner of say 'bill.gates@microsoft.com', he can register, but the preexisting account with 'bill.gates@microsoft.com' being username would be blocked or renamed.
3: The probably most diligent solution:
Allow potentially valid email addresses only as username if at the time of registering or changing username, the username matches the current email address. If at a later point someone registers proving to be the new owner of say 'ceo@microsoft.com', a preexisting account with the username 'ceo@microsoft.com' might be blocked, but would in any case be renamed and the owner informed.

And what to do with existing usernames on existing sites?
Taking the latter solution from above, we could adopt:

3a: The most rigid solution:
Block, rename and inform users with a user name which might potentially be an email address, but doesn't match the currently given email address.
3b: The minimum solution:
Rename and inform only users which user name matches the email address of another account. Leave all other accounts alone someone else proves ownership of the email address.
3c: The probably most diligent solution:
Rename and inform users which user name matches the email address of another account. Inform and require all other users with a username being a potential email address to prove ownership within some time, otherwise rename the account.

Opinions?

CommentFileSizeAuthor
#78 check_usernames_that-2014185-78.patch8.84 KByogeshmpawar
#74 check_usernames_that-2014185-74.patch8.78 KBhitesh-jain
#65 2014185-65.patch8.78 KBmgifford
#60 2014185-60.patch8.91 KBrpayanm
#54 2014185-54.patch11.5 KBYesCT
#51 2014185-51.patch11.49 KBdamiankloip
#50 interdiff-2014185-48.txt5.4 KBdamiankloip
#50 2014185-48.patch11.49 KBdamiankloip
#42 interdiff-2014185-42.txt1016 bytesdamiankloip
#42 2014185-42.patch11.11 KBdamiankloip
#40 interdiff-2014185-40.txt1.3 KBdamiankloip
#40 2014185-40.patch10.99 KBdamiankloip
#38 interdiff-2014185-38.txt1.05 KBdamiankloip
#38 2014185-38.patch10.99 KBdamiankloip
#36 interdiff-2014185-36.txt912 bytesdamiankloip
#36 2014185-36.patch10.99 KBdamiankloip
#34 interdiff-2014185-34.txt6.96 KBdamiankloip
#34 2014185-34.patch11 KBdamiankloip
#30 interdiff-2014185-30.txt7.86 KBdamiankloip
#30 2014185-30.patch10.52 KBdamiankloip
#26 interdiff-2014185-26.txt801 bytesdamiankloip
#26 2014185-26.patch10.49 KBdamiankloip
#24 interdiff-2014185-24.txt2.08 KBdamiankloip
#24 2014185-24.patch10.48 KBdamiankloip
#23 2014185-23-reg-form.png246.33 KBdamiankloip
#23 2014185-23-settings-form.png390.3 KBdamiankloip
#23 interdiff-2014185-23.txt784 bytesdamiankloip
#23 2014185-23.patch10.42 KBdamiankloip
#21 interdiff-2014185-21.txt1.95 KBdamiankloip
#21 2014185-21.patch10.57 KBdamiankloip
#20 2014185-20.patch10.53 KBdamiankloip
#19 interdiff-2014185-19.txt1.95 KBdamiankloip
#19 2014185-19.patch10.72 KBdamiankloip
#17 2014185-17.patch10.74 KBdamiankloip
#16 interdiff-2014185-16.txt6.69 KBdamiankloip
#16 2014185-16.patch10.75 KBdamiankloip
#10 interdiff-2014185-10.txt5.07 KBdamiankloip
#10 2014185-10.patch6.19 KBdamiankloip
#6 drupal8.username_email_mismatch.2014185-6.tests-only.patch3.73 KBZenDoodles
#4 username-email.png241.41 KBZenDoodles
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

no2e’s picture

Asking bluntly: Do we really need to allow two login names (email adress or username) in D8? Couldn’t it be an option to remove this feature altogether and stick to one way?

Then we’d only have to solve "And what to do with existing usernames on existing sites?".

Pancho’s picture

Thanks for bringing this up again! However:

Do we really need to allow two login names (email adress or username) in D8?

There's nothing to remove. It's not yet implemented.
However #111317: Allow users to login using either their username OR their e-mail address might add login via email address, which is a very common and therefore much requested feature. And removing login via username is an absolute no-go for existing sites.
Also, why would we want to do that? Because:

Then we’d only have to solve "And what to do with existing usernames on existing sites?".

No, this issue is independent from that question. If #111317: Allow users to login using either their username OR their e-mail address lands, the problem would only become more apparent.

YesCT’s picture

Title: Check email addresses registered as username more rigidly » Check usernames that are email addresses more rigidly, only allow if matches email

proposed solution 3 seems like the best one.

We only allow email addresses as a username if the username matches the email address.

----

I think what to do about existing data (the upgrade path) is a hard problem that should be a separate issue.
For this issue, we dont do anything with existing data, our upgrade path is that the data stays the same. And then it is only a problem when people try and save some change in their account.

----

Note, this has email verification for sites that *have* email verification turned on.

ZenDoodles’s picture

FileSize
241.41 KB

@YesCT, @Les Lim, @SeanKelly, and I discussed this at a code sprint (in Twin Cities) and we believe this issue and #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account are distinct issues. We like the following workflow:

username-email.png

ZenDoodles’s picture

Issue summary: View changes

linkfix

tim.plunkett’s picture

Category: Bug report » Feature request
Issue summary: View changes

Sorry, not a bug.

ZenDoodles’s picture

This patch is tests-only and should fail.

It tests:

  1. Users should not be able to register with an email address as their username unless it is their own email address.
  2. Users should not be able to change their username to an email address unless it is their own email address.

Also, @tim.plunkett I disagree. I think allowing a user to set their username to an email address which is not their own is a bug, and arguably a significant privacy issue. @See also #1359718-138: Allow password reset on account with the username matching another email; prevent registrations that match another account

ZenDoodles’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 6: drupal8.username_email_mismatch.2014185-6.tests-only.patch, failed testing.

The last submitted patch, 6: drupal8.username_email_mismatch.2014185-6.tests-only.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
6.19 KB
5.07 KB

Bug, feature, whatever :) I think this is a handy thing to have.

How about something like this? I went with PHO's email validation as I assume if it is just something like john@smith we don't really care? Only a legit email address is being used for the user name?

Had the change the tests a little, I think it was just some stuff that didn't quite get changed from copy pasting.

EDIT: although seems like d.o thinks that's an email address and has added a mailto: to it. HA..

catch’s picture

What about existing users like https://drupal.org/user/227 ?

damiankloip’s picture

Good point. As this is 8.x won't this only be an issue for user migrations?

catch’s picture

It looks from the patch like the validation runs whenever the account is updated via the form. So if we retain usernames during the migration you'd still need to be able to re-save your account without changing the username.

The other option would be forcing people to update their username when they edit their account, but that feels like a choice for site-admins.

damiankloip’s picture

So what are we saying? Wes should just make this a setting? Seems it will get hard to do otherwise.

mgifford’s picture

If it is a setting, can we ensure it is enabled by default? Where would be the best place to place this option?

damiankloip’s picture

FileSize
10.75 KB
6.69 KB

Spoke to catch about this and decided it would suffice to just add a settings to enable/disable this functionality would be fine. Defaulting to on. Additional tests added too.

Advice on the wording for the form etc.. most welcome.

damiankloip’s picture

FileSize
10.74 KB

Rerolled.

Status: Needs review » Needs work

The last submitted patch, 17: 2014185-17.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
10.72 KB
1.95 KB
damiankloip’s picture

Issue tags: -#SprintWeekend2014
FileSize
10.53 KB

Reroll.

damiankloip’s picture

FileSize
10.57 KB
1.95 KB

Some text tweaks after speaking to catch.

Status: Needs review » Needs work

The last submitted patch, 21: 2014185-21.patch, failed testing.

damiankloip’s picture

Issue tags: +Needs usability review
FileSize
10.42 KB
784 bytes
390.3 KB
246.33 KB

Catch also suggested just removing the description, which is 100% fine with me.

Tagging with 'Needs usability review' so one of the UX folks can cast their eyes on the new option. Screenshots attached too.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
10.48 KB
2.08 KB

Forgot to fix the tests too.

Bojhan’s picture

Issue tags: -Needs usability review

Interesting, I like the solution that is shown here. But a couple of questions:

1) Shouldn't we enable this by default? In 99% of the cases, we are helping the webmaster by mitigating this problem.
2) The label could be more clear. I am just not sure how, because you mention e-mail and username each twice, which makes it harder to scan.

damiankloip’s picture

FileSize
10.49 KB
801 bytes

Thanks for looking over this.

+++ b/core/modules/user/config/install/user.settings.yml
@@ -1,6 +1,7 @@
+verify_email_match: true

This does default to true. The screenshot I took just didn't have it on.

Here is a new patch based on the discussion about the option text.

Bojhan’s picture

That looks better! I really love our attention to detail on these kind of things.

"When an e-mail address is used as username, require a matching e-mail address."

Its a little verbose since it needs to match both registration and usage after registration. However it is something that can be scanned more quickly now.

damiankloip queued 26: 2014185-26.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 26: 2014185-26.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
10.52 KB
7.86 KB

Rerolled. Mostly form state object changes.

damiankloip’s picture

Ignore the whitespace in the diff, not in the patch. Not sure what happened there..

Status: Needs review » Needs work

The last submitted patch, 30: 2014185-30.patch, failed testing.

LinL’s picture

+1 for this change.

Haven't fully tested it, but a nitpick - since #950534: [policy] Consistently use "email" instead of "e-mail" in Drupal we're using email instead of e-mail.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
11 KB
6.96 KB

Nice, thanks for linking that issue. Also fixed the fatals now randomName() doesn't exist anymore.

Status: Needs review » Needs work

The last submitted patch, 34: 2014185-34.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
10.99 KB
912 bytes

Missed one of the form state changes.

Status: Needs review » Needs work

The last submitted patch, 36: 2014185-36.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
10.99 KB
1.05 KB

Missed a s/e-mail/email change.

LinL’s picture

Still a couple more e-mails! 2 in the yml file and 1 in test comments:

+ verify_email_match:
+ type: boolean
+ label: 'Require e-mail and username match when e-mail is used as username.'
+ */
+ public function testRegistrationEmailAsUsername() {
+ // Don't require e-mail verification.
damiankloip’s picture

FileSize
10.99 KB
1.3 KB

Good spot! Forgot about the schema files.

dawehner’s picture

General question: Shouldn't we adapt the description of the name field to explain that you can actually enter an email address? In case the verify_email_match is set
the text could explain that in case you specify a mail, it should be the same?

I could imagine that users might not have the idea to try out their email adress as well.

+++ b/core/modules/user/src/AccountForm.php
@@ -334,19 +338,24 @@ public function validate(array $form, FormStateInterface $form_state) {
+        if (\Drupal::config('user.settings')->get('verify_email_match') && (filter_var($name, FILTER_VALIDATE_EMAIL) && ($name !== $mail))) {
+          $form_state->setErrorByName('name', $this->t('You have provided an email address as a username, but this does not match your email address.'));
         }

* You can just use $this->config() instead.
* Don't we have abstracted away the validation using symfony validator? Could we use that to replace that filter_var call? Read more about this mess in https://www.drupal.org/node/2313669

damiankloip’s picture

FileSize
11.11 KB
1016 bytes

Thanks for the review! So:

- I would like to punt any other user facing changes to a follow up if we can. That seems like a discussion by itself, and this issue has been hanging around long enough.
- User $this->config()
- Added @todo to use Symfony validator when #2313669: Bring in egulias/EmailValidator for RFC compliant email address validation is committed.

How about that?

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

I'm cool with it

The last submitted patch, 23: 2014185-23.patch, failed testing.

Dries’s picture

Priority: Major » Normal

I'm moving this to 'Normal'.

alexpott’s picture

Category: Bug report » Feature request

Is this really a feature we need to add to core? This is a problem - https://www.drupal.org/u/driesbuytaert.net but is has been this way for years. Interesting the d.o user registration form says "Spaces are allowed; punctuation is not allowed except for periods, hyphens, apostrophes, and underscores." as help text for the user name - this is obviously incorrect.

+++ b/core/modules/user/src/Tests/UserEditedOwnAccountTest.php
@@ -36,5 +39,28 @@ function testUserEditedOwnAccount() {
+    // Change username to my email address.
+    $edit['name'] = $this->randomMachineName() . '@example.com';

The comment is incorrect - we're changing to a random non matching email address here.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs work
+          ->condition('name', $name)
+
           ->range(0, 1)
           ->count()

??? - (fix this on commit if there were nothing else wrong)

+        // @todo Replace email validation with Symfony validator when
+        //   https://www.drupal.org/node/2313669 is in.
+        if ($this->config('user.settings')->get('verify_email_match') && (filter_var($name, FILTER_VALIDATE_EMAIL) && ($name !== $mail))) {

Why isn't this just using valid_email_address()? Any @todo can be on that function directly.

+          $form_state->setErrorByName('name', $this->t('You have provided an email address as a username, but this does not match your email address.'));

This wording doesn't make a whole lot of sense when an administrator is editing someone else's account...

+    $this->assertNoText(t('If your username is an email address, it must match your email.'), 'Email username does not match user email error message found.');

This is asserting the absence of a message that is not actually used anywhere in the actual code.

---

Overall looks nice. This seems like it should be backportable to Drupal 7 (especially with the optional setting).

damiankloip’s picture

Status: Needs work » Needs review

Thanks for the feedback. I don't think this should be demoted to normal but meh.

@alexpott, I think this is a useful core feature, something that we should definitely have. Precisely for the reason outlined in the account you created. You could now go and cause havoc in the queue as dries@buytaert.net very easily. This is also a better fix IMO to some of the related issues that try to dance around with checking usernames and emails when doing password reset. Plus, the fact that this has been the case for some time is not a good reason to not fix it :) Fixed the test comment also.

@David_Rothstein, Yes I would like to see this backported. As it's is controlled by an option. Should not break anything. Fixed the comments from #47. Let me know what you think of the text change. This should make more sense in both contexts now.

LinL’s picture

Patch missing from #48?

damiankloip’s picture

FileSize
11.49 KB
5.4 KB

Yep!

damiankloip’s picture

FileSize
11.49 KB

Rerolled.

Anyone?

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Feedback got adressed.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 51: 2014185-51.patch, failed testing.

YesCT’s picture

Status: Needs work » Needs review
FileSize
11.5 KB

We still need a separate issue to correct the help text as identified by @alexpott in #46
Here is one #2354129: correct help text for account creation email address field.
I think it will need correcting wether or not this gets in.

rerolled for #1802128: Replace "user name" with "username" in UI text

mgifford’s picture

Ok, so this passes the bot. It has been RTBC'd a few times so I assume it's just fine now. Still, what other testing should be done (if any)?

I'm not clear from the summary (or the last issue) which solution is being pursued, so looking for a summary update.

kaare’s picture

damiankloip queued 54: 2014185-54.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 54: 2014185-54.patch, failed testing.

Anonymous’s picture

Issue tags: +Needs reroll
rpayanm’s picture

Status: Needs work » Needs review
FileSize
8.91 KB

Trying...

Status: Needs review » Needs work

The last submitted patch, 60: 2014185-60.patch, failed testing.

vermauv’s picture

Issue tags: -Needs reroll

Status: Needs work » Needs review

b0unty queued 60: 2014185-60.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 60: 2014185-60.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
8.78 KB

Just a straight re-roll of #60.

patching file core/modules/user/src/Tests/UserRegistrationTest.php
Hunk #1 succeeded at 223 with fuzz 1 (offset 73 lines).

Status: Needs review » Needs work

The last submitted patch, 65: 2014185-65.patch, failed testing.

The last submitted patch, 65: 2014185-65.patch, failed testing.

damiankloip’s picture

The code that actually does the validation is missing :) (Missing from #60 too). We can probably implement this using some validator now too?

AaronBauman’s picture

I'll volunteer to re-roll a patch that includes the validation mechanism.

I can think of at least 3 ways to do this:
* add a validate() method on user entity
* update UserNameConstraint to conditionally verify email based on user setting config
* create a new constraint which is conditionally added to user field definitions

Any of these make the most sense?
A different approach?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jonathanshaw’s picture

Issue tags: +Needs reroll
hitesh-jain’s picture

Version: 8.2.x-dev » 8.3.x-dev
Assigned: Unassigned » hitesh-jain
hitesh-jain’s picture

Assigned: hitesh-jain » Unassigned
Status: Needs work » Needs review
FileSize
8.78 KB

Rerolling against 8.3.x branch.

Status: Needs review » Needs work

The last submitted patch, 74: check_usernames_that-2014185-74.patch, failed testing.

The last submitted patch, 74: check_usernames_that-2014185-74.patch, failed testing.

yogeshmpawar’s picture

Assigned: Unassigned » yogeshmpawar
yogeshmpawar’s picture

Assigned: yogeshmpawar » Unassigned
Status: Needs work » Needs review
FileSize
8.84 KB

I have rerolled the patch against #74.

Status: Needs review » Needs work

The last submitted patch, 78: check_usernames_that-2014185-78.patch, failed testing.

Manuel Garcia’s picture

Issue tags: -Needs reroll

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Anybody’s picture

This is still an important improvement and security precondition for #111317: Allow users to login using either their username OR their e-mail address. The current situation also allows for easier social engineering, if an email address doesn't match the username or even the email address or username of someone else.