-
-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update generate password logic to use proper methods #16521
Conversation
fix length issue Tweaks
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## 3.x #16521 +/- ##
============================================
- Coverage 21.68% 21.66% -0.03%
Complexity 10496 10496
============================================
Files 561 561
Lines 31703 31698 -5
============================================
- Hits 6875 6867 -8
- Misses 24828 24831 +3 ☔ View full report in Codecov by Sentry. |
I've got a couple general questions on this before doing a quick review:
if (!empty($options['alphabet'])) {
$alphabet = array_merge(range('a', 'z'), range('A', 'Z'));
shuffle($alphabet);
return substr(implode($alphabet), 0, $length);
} in other words, is something like this what you're really going for? $alphabet = empty($options['alphabet'])
? array_merge(range('a', 'z'), range('A', 'Z'))
: $options['alphabet']
;
shuffle($alphabet);
return substr(implode($alphabet), 0, $length); |
Hmm, I overlooked the change from I'd be fine with removing that block entirely and limiting the functionality of this method to only the new generation with |
Yeah, my guess is there's likely been no usage of that method outside of the core. If, however, there has been and a dictionary were passed in via |
Looking at this again I see what you mean when you imply the change (changing the options key in question) wouldn't break anything. It might cause unexpected output if there was external use of this method where chars and/or a custom seed were passed into the $options, but would not prevent a password from being generated. I get now that your changed variable is meant to be a boolean value, not a character set (in which case a key of something like 'use_alpha_chars' would be more clear). At any rate, I'd still say drop that block altogether because the new generation logic you added below it will create a better password anyway. Further, I'd even move toward making this method private and removing its params, making it even more clear that this is a utility method meant for internal use only. After all, I think the intention is that these passwords are temporary ones that users should immediately change. |
I'd agree with @smg6511 and nuke everything but the length & bin2hex usage :) However I'd keep the signature same (even though |
What does it do?
Re-up of #15894
Changes password generation method to be more secure.
Why is it needed?
Actually random generation.
How to test
Apply and see passwords still get generated.
Related issue(s)/PR(s)
Re-up of #15894
Fixes #15740