Make Automatic User Names compatible with Generate Password module.

Maybe I have to add: I did not change the configuration. Everything worked fine in alpha version.
The username does not contain illeagal characters!

Hi @maxilein,

I haven't been unable to reproduce this issue so I'm not sure what is causing this for you.

I can't see how it would be the Password Compatibility module as this works on users with existing users when the log in to replace any old password hashes stored in the database. This is after genpass involvement as the user already exists.

Steps, all of which worked without error:

• Install fresh 10.1 site
• Install genpass:2.0.0-alpha1 (manually; composer jumps to next version)
• Create user via admin
• Create user via visitor registration
• Upgrade to genpass:2.0.0
• Create user via admin
• Create user via visitor registration

Have you implemented hook_genpass_user_forms and told genpass to push a password into the username field? This would end up with password characters in the username alright, but it would be a mis-configuration rather than a bug.

Could you provide any more steps or configuration which would help in reproducing the problem?

This is the code which is being triggered in UserNameConstraintValidator.php so one of these characters is ending up in the username. None of these should be provided by genpass.

<?php
if (preg_match('/[^\x{80}-\x{F7} a-z0-9@+_.\'-]/i', $name)
      || preg_match(
        // Non-printable ISO-8859-1 + NBSP
        '/[\x{80}-\x{A0}' .
        // Soft-hyphen
        '\x{AD}' .
        // Various space characters
        '\x{2000}-\x{200F}' .
        // Bidirectional text overrides
        '\x{2028}-\x{202F}' .
        // Various text hinting characters
        '\x{205F}-\x{206F}' .
        // Byte order mark
        '\x{FEFF}' .
        // Full-width latin
        '\x{FF01}-\x{FF60}' .
        // Replacement characters
        '\x{FFF9}-\x{FFFD}' .
        // NULL byte and control characters
        '\x{0}-\x{1F}]/u',
        $name)
    ) {
      $this->context->addViolation($constraint->illegalMessage);
    }
?>

Thank you. I will further investigate on the weekend.

I uninstalled genpass alpha1 and installed 2.0.1. Same results.

Very tricky: Maybe it is a incompatibility with https://www.drupal.org/project/auto_username → ?
If I disable it I have to add the account manually.

The scenario: I just want to enter the given and family name manually and derive the account name and password automatically.
(I also use the realname module to display the name with more details sidewide (2.0.0-beta2).)

Here is what worked:
I am using the name field module https://www.drupal.org/project/name → (current 8.x-1.x-dev). This provides tokens for given and family seperately.
To automatically create the account name I am using the pattern
[user:field_name_name:given].[user:field_name_name:family] from https://www.drupal.org/project/auto_username → (auto_username
Version: 8.x-1.5).
And genpass automatically creates the password.

I can only think of some changes in the order function calls?
Does this help you?

When using genpass alpha1 everything works (Version: 2.0.0. and Version: 2.0.1 don't)

I went back to alpha1.

I can confirm that installing and configuring auto_username:1.5.0 with default settings is causing the error! Does not need the name field to be added.

First inkling of weirdness is that genpass does not even manage to run post-submission before the error has turned up, which is when it actually does the setting of the password value. Before that it's just changing the visibility of a few fields. I've checked that there aren't any clashes in form key names. Tokens are used and genpass adds tokens to the user bag but getting a bad name would mean adding [user:password] as the username!

Anyway, having a poke around to see what on earth it could be.

Ah ... ok? This is why
https://git.drupalcode.org/project/auto_username/-/blob/8.x-1.x/auto_use...

/**
 * Implements hook_form_FORM_ID_alter().
 */
function auto_username_form_user_register_form_alter(&$form, &$form_state, $form_id) {
  $form['account']['name']['#type'] = 'hidden';
  $form['account']['name']['#value'] = \Drupal::service('password_generator')->generate();
}

That's just not going to work with genpass. The bad username is because it is being set to a literal bad username and Drupal core let try to save it before the real username is generated and added during hook_user_insert. None of the sanitation or cleanup is happening, it's just going straight into Drupal username validation.

That needs to use something else to come up with a random username to handle that part of the process. It's auto_username that's going to need a patch.

Moving this over to Automatic User Names as they'll need to patch to not set of the username to a password in the user creation form.

Attached is a patch to use the uuid service to generate the name instead, which is guaranteed to pass UserNameConstraintValidator as a UUID is always generated according to RFC 4122.

Well,
but genpass alpha1 is working with this module...
just saying...

As per the release notes of genpass:2.0.0 and issue linked below and as part of that note, this is a significant change from the alpha release of genpass.

Developers note

• The hook_generate() implemented by this module has been removed in favour of a service implementing Drupal\Core\Password\PasswordGeneratorInterface. Genpass now installs itself as the default password generating service of the site, with option to use pass through to DefaultPasswordGenerator.

And relevant issue: 📌 Add PasswordGeneratorInterface based service. Remove hook_password Fixed

Given the release note above, you could choose to turn off the enhanced password generation and use Drupal core generation which would mitigate the illegal character issue also.

If you wish to continue to use the alpha release into the future, please be aware of the bugs listed in the release notes which may or may not be relevant to you. Here's the full release note: https://www.drupal.org/project/genpass/releases/2.0.0 →

The patch provided here fixes auto_username so that both modules could continue to kept updated to latest versions and faultlessly use all their features.

Thank you very much!
I can confirm that this patch works perfectly.

Confirming that #8 is the correct and a simple solution, as using the password generator was also kind of hacky ;)

@ELC thank you very much for the patch. Typically MR's are preferred and speed up fixes a lot, as it's easier for the maintainer to review and merge.

Thanks for this simple improvement :) Merge request committed.

Automatically closed - issue fixed for 2 weeks with no activity.