Closed (fixed)
Project:
Password Policy
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
3 Sep 2015 at 12:47 UTC
Updated:
7 Apr 2024 at 21:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
oleksiydo-not-test patch is for 7.x-2.0-alpha5.
Comment #3
aohrvetpv commentedIf it is possible to detect account password elements on a form, and call
password_policy_password_element_alter()for them, I think that would be preferable to adding a hook. This solution requires other modules to know about Password Policy (i.e., add Password Policy integration code). Ideally, Password Policy would not need to know about other modules, and other modules wouldn't need to know about Password Policy.Comment #4
oleksiyThen we can totally remove a check for form_id and to check only if password_confirm form element exists in the form. Then Password Policy module can apply its rules for forms provided by other modules if they have the same form element. Also it will be useful in case we have replaced default user register\profile\password recovery pages.
Comment #5
andypostLooks nice, except why the altering removed in last patch?
Comment #6
oleksiyAlter was in _password_policy_is_covered_form() function which was removed in the last patch.
Comment #7
tessa bakkerPatch #4 works nice on custom forms.
Much cleaner and more reliable, there isn't any need for an alter now.
Comment #8
aohrvetpv commentedComment #10
aohrvetpv commented7.x-1.x hardcodes form IDs but I think it would be better not to make this change in that branch until it has been tested for a while through use.
Comment #11
andypostComment #12
deivamagalhaes commentedHello, first of all, thank you for the patch.
I am using it on top of 7.x-1.x-dev and I had to make some changes in order to use password policies in a custom form with fieldsets. Basically, what I am doing is getting the password elements from the form based only on their type, regardless of their name or their position on the form structure (inside a fieldset or not). Feel free to contact me if you have any questions about my changes.
Comment #13
deivamagalhaes commentedNew version fixing some details to get even more custom forms.
Comment #14
deivamagalhaes commentedNew version if the custom form uses container instead of fieldset.
Comment #15
deivamagalhaes commentedI have found another scenario that requires adjustments. When you are using a custom registration form, the policy is not loaded correctly, because the code is only checking for the specific form_id user_register_form. I've adjusted to check for the anonymous role. If the user is not logged in, he is trying to register (it is a registration form).
Please find attached the new patch containing this change.
Comment #16
oleksiyThanks for the patches. Looks good. But, may be, we can alter "password_confirm" element directly without need to look for the element in the form. hook_element_info_alter() should help to add a new "#process" or "#after_build" function where we can add Password Policy related data. What do you think?
Comment #17
andypost@Oleksiy Nice idea +1
Comment #18
aohrvetpv commentedTook a quick look at #15. It seems like it finds all elements of type 'password_confirm'? Problem is a 'password_confirm' is not necessarily used for an account password. It's just a Form API control type that you can use for any sort of password requiring confirmation. That is, not all 'password_confirm' elements are necessarily for account passwords. Please correct me if wrong.
Commit in #9 ensures they are account password elements by requiring the presence of the 'account' array key.
Comment #19
aohrvetpv commentedPorted #4 to 7.x-1.x.
This should apply password policies to account password elements on custom forms.
Comment #20
aohrvetpv commentedComment #22
aohrvetpv commentedFixed Password Change Tab submodule to work with changes from #19.
Comment #23
aohrvetpv commentedMoved function to different section of file for consistency.
Comment #25
aohrvetpv commentedNow implemented in 7.x-1.x and 7.x-2.x.
Comment #26
dakku commented++ D8
cross ref: https://www.drupal.org/project/password_policy/issues/2924009
Comment #27
kristen polThanks everyone for their work on this issue.
Given #2924009: Apply password policies to password elements on custom forms is working on the D8+ version, closing this as fixed for Drupal 7.
Comment #28
kristen polAnd closing.