If

[ ] Disable login failure error message

is checked, then we expect to see the result explained in the code comment:

        // Removes "Sorry, unrecognized username or password. Have you
        // forgotten your password?" and "The username $name has not been
        // activated or is blocked.", and any other errors that might be
        // helpful to an attacker it should not reset the attempts message
        // because it is a warning, not an error.

However, there are a bunch of issues with the code, as reported by
#2901332: Logic error: if (!count($password_message) || !count($block_message)) is always TRUE
#2661906: Unknown modifier 'b' in login_security_validate()
#2928845: Unknown modifier 'a' in login_security_validate()
and there's more: You're trying to match part of the English message, but if the site uses any other language, you'll obviously never get a match. Presently, because the condition is always true (see the first linked issue), we could just do away with the entire matching and checking, and get the same result.

The whole thing is an attempt to guard against unexpected error messages other than the two mentioned ones. This makes sense, because if there's an unexpected error, we want to know about it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

salvis created an issue. See original summary.

salvis’s picture

Status: Active » Needs review
FileSize
1.66 KB

The fix has four parts:

  1. match the (entire) translated (!) message
  2. guard against meta characters and slashes that may be part of the translations and/or replacement variables
  3. use url() for proper url encoding
  4. fix the condition