The attached component inc file creates a standard Drupal password field with confirm, strength testing and match checking. It will validate that the passwords match. It uses the validation javascript from the user module.
This component does nothing with the password field data beyond saving it in the webform_submitted_data table. What to do with the password is up to you to handle in webform's additional validation and processing sections.
WARNING: Webform itself has nothing to do with passwords. It will treat this password field as any other text field. It is not automatically encrypted. It will display the password if you let it, potentially exposing users' passwords to whoever has access to webform results or to your database.
You should eliminate this security risk by emptying or encrypting the pass field after you're done with it and before the form is stored in the db. This must be done in the additional processing section. Further, make sure that the pass field is not emailed.
Use Case: My use case for this was a complicated application collecting much of the user registration data. Because we were collecting all that data, the client wanted to give anonymous users the opportunity to create an account at the same time. In my additional processing section, I check if we're creating a new account. If so I pass the $form_state to a custom function where the account is created. After creating the account I replace the password with **** to be stored, so the admin can see that a pass was entered.
The attached file goes in /sites/all/modules/webform/components.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | password_confirm.inc_.txt | 9.32 KB | awolfey |
Comments
Comment #1
awolfey commentedHere's the file. Remove the underscores and the .txt at the end to use.
Comment #2
quicksketchI think I would prefer not to have Webform handle the potential security repercussions of storing passwords. I'd suggest this be made into a separate module through the Webform Component API introduced in #340241: Provide hook_webform_component_info() to allow 3rd-party components
Comment #3
josepvalls commentedWebform shouldn't handle passwords, agreed. But having a password component can have many uses.
Right now I want to have a form for users to submit questions, but I want them to input a username/password that will be used in post_processing to authenticate via third party API, and will never be stored.
That is a fair use of a password component in the webform.
Comment #4
quicksketchIt may be good for your use-case, but having a password field for that purpose alone is not enough reason to include one. The expectation for a password field is that it needs to match some existing password, or that you will be setting a password for matching against later. Since Webform doesn't provide (or require) either of these situations, adding a password field that doesn't store anything in the database would be immensely confusing to users when compared to the operation of all other fields.
Though as I said in #2, adding this as a separate module so that we don't encumber the core module with such an edge-case is still fine. This just won't be added to Webform itself.
Comment #5
crystaldawn commentedI have the exact same use case as #1. If this work hasnt yet been put into a working module, then I'll likely be posting back here stating that I swiped his code and stuffed it into a module and commited it and I'll post the link at that time. If I dont come back here, then creating a module wasnt feasible for some reason or another.
Comment #6
crystaldawn commentedDisappointing, this fix isnt valid for the current version of webform 3.x :/ shoulda looked at the version tag here. Duh. I guess its time to re-invent the wheel :/ I'd have to disagree with sketch in that pw field isnt something that would be useful though. It's not uncommon for webforms to be very long and having the user go to the user registration page doesnt make any sense when they could do it right from the webform itself (This isnt something the webform module would handle of course, only providing the pw field itself is what webform needs to do, what the user does with it is up to them in the validation/post processing). There are more use cases than I can shake a stick at where a pw field would be beneficial regardless of the security implications. I'd hate for car manufacturers to tell me that I have to go buy a door lock at walmart because of the "security implications" lol. Just because its possible that someone mighty not use it properly doesnt mean it shouldnt be there ;) Fear is never a good thing. Dont fear boy! The grass really is greener over there, as long as you keep the lawn mowed lol (means keep it up to date and vigilant in the security process lol).
Comment #7
crystaldawn commentedOk, well I've cobbled together a working module but I have left it sandboxed until it's been through some testing to prove that it's secure. It's temporary URL is http://drupal.org/sandbox/drupalstarz/1099028 The ONLY way to get the files is to use GIT. If you do not know how to use git, then this project is likely not for you. If you know how to use git, then feel free to take a look at it, make feature suggestions, and submit bug reports. Any further issues placed on the webform module regarding password type fields are welcome to be re-directed to this module. The more use it gets, the quicker I will feel that its ready to be promoted to a full project. This module requires Webform 3.x and per quicksketches wishes it uses the webform hooks whenever possible.
Also as of right now it is EXTREMELY barebones. It has NO brains at all. It doesnt do strength validations, it doesnt encrypt data, and it doesnt create an extra "confirm" field for use. Currently I leave those up to the developer using the module to piece together. About the only thing it does in the way of validations is make the drupal password validation code available (I stole this idea from #1 in this thread).
Comment #8
quicksketchGreat to see this in a separate project, but as before, I won't be adding any password fields directly into Webform.