Password field errors on user create/edit/login when password is (literally) 0

I added a test.

The novice task is to offer a review.

+++ b/core/modules/user/src/Tests/UserCreateTest.php
@@ -114,5 +114,19 @@ public function testUserAdd() {
+    $edit = array(
+      'name' => $name,
+      'mail' => $this->randomMachineName() . '@example.com',
+      'pass[pass1]' => 0,
+      'pass[pass2]' => 0,
+      'notify' => FALSE,
+    );

I wonder if the zeros in the form steps should be quoted as strings.

Hi,
revised both patches on a fresh D8 install:
- Confirmed that fail test actually fails.
- Confirmed that the test after applying the patch passes correctly.

Apt to be labeled as RTBC

Regards,
Imanol

You can now log in with that user. UserAuth also used empty($password), changed that to strlen as well.

Added a test for UserAuth to prevent regressions.

Added a test for the pass/confirm fields on user edit.

Tested this patch password_field_errors-2563751-19.patch. It works fine. Manually verified that I am able to create a user with password 0 and able to login with same password after applying the patch. Screenshots attached.

I don't think the failures in #19 are related to this issue, They're all installer related and this doesn't touch Installer code.

I uploaded the patch from #19 again here. If this passes I think it can go back to RTBC (per #20)

Tested password_field_errors-2563751-19_0.patch on Firefox and chrome for Ubuntu 14.04. It works fine. Manually verified that creating a user with password '0' is allowed and user can able to login successfully with same password after applying the patch.
Screenshots attached.

This is a funny issue and obviously no one should have a password of 0 but 0 is just as valid as 1. Committed fb8e894 and pushed to 8.0.x. Thanks!

I'll backport this issue to drupal 7.

Managed to port it to Drupal 7. Automatic and manual tests all worked. Please review!

Tested 2563751-29.patch.It works great.thanks for the patch.

Hi pietmarcus,
Your patch works great as per our need.

worked fine.

There is a lot of mismatch of using trim() + strlen() and only using strlen(), but D8 has the same and sync of code is more important to me.

I think we make it impossible to use " " as password now. But I think empty was empty before, so its not a regression and " " might indeed be considered as fill out the password field ...

Marked for commit.

Yeah, at least when you create a user account via the UI a password of " " seems like it's blocked already, so I think that's OK. And if we're wrong and this issue results in blocking the ability of someone who actually has a password of " " from logging in, that's not a bad thing since they really should change their password anyway :)

I removed the following on commit, since we don't reference issues like that unless there's a very specific reason to do so (I realize the Drupal 8 tests have this too, but it's only a code comment change and can be removed in Drupal 8 later if desired):

diff --git a/modules/user/user.test b/modules/user/user.test
index bcb92c1..92901b4 100644
--- a/modules/user/user.test
+++ b/modules/user/user.test
@@ -1879,7 +1879,6 @@ class UserCreateTestCase extends DrupalWebTestCase {
     }
 
     // Test that the password '0' is considered a password.
-    // @see https://www.drupal.org/node/2563751.
     $name = $this->randomName();
     $edit = array(
       'name' => $name,
@@ -1971,10 +1970,6 @@ class UserEditTestCase extends DrupalWebTestCase {
 
   /**
    * Tests setting the password to "0".
-   *
-   * We discovered in https://www.drupal.org/node/2563751 that logging in with a
-   * password that is literally "0" was not possible. This test ensures that
-   * this regression can't happen again.
    */
   public function testUserWith0Password() {
     $admin = $this->drupalCreateUser(array('administer users'));