Enhancing password article. #334
Conversation
EHandtkeBasis
requested review from
hyyan,
MatthewHawkins,
nmlynx and
mschned
as code owners
EHandtkeBasis
force-pushed
the
password-field-enhance
branch
from
97b5817 to
3128e52
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
/rebase |
github-actions
bot
force-pushed
the
password-field-enhance
branch
from
f5d94b3 to
259f63c
Compare
|
@EHandtkeBasis also add |
| The `PasswordField` component stores and retrieves its value as a plain `String`, similar to a `TextField`, but with obscured visual rendering to hide the characters from view. | ||
|
|
||
| You can retrieve the current value using: | ||
|
|
||
| ```java | ||
| String password = passwordField.getValue(); | ||
| ``` | ||
|
|
||
| To set or reset the value programmatically: | ||
|
|
||
| ```java | ||
| passwordField.setValue("MySecret123!"); | ||
| ``` | ||
|
|
||
| If no value has been entered by the user and no default is set, the field will return an empty string (`""`). | ||
|
|
||
| This behavior mimics that of the native HTML `<input type="password">`, where the `.value` property holds the current input. | ||
|
|
||
|
|
||
| :::tip | ||
| Although the field visually masks the content, the returned value from `getValue()` is still stored as a plain string. Be mindful of this when handling sensitive data. | ||
| ::: |
There was a problem hiding this comment.
@EHandtkeBasis There's a conflict in messaging in this article. The beginning of this section starts with:
"The PasswordField component stores and retrieves its value as a plain String..."
However, one of the Best Practices points states:
"Ensure Secure Password Storage: Never store passwords in plain text...."
It's briefly mentioned in the tip, but at what point does the user have to start encrypting a password value? Is it ok to use String password = passwordField.getValue();, or should the password never be declared as a String variable?
Does the convertValue() method help resolve this?
There was a problem hiding this comment.
This is referring to the fact that the field internally operates with plain strings, as soon as the value is retrieved it should be transformed according to the apps security standards for example with hashing. This is what the best practices refer to. Something like String password = passwordField.getValue() should be avoided.
There was a problem hiding this comment.
Ok, if String password = passwordField.getValue() should be avoided, then don't include it as an example (Lines 29-31). I'd then suggest moving the tip at the bottom of this section to where that getValue() snippet used to be and state that developers should transform the value before storing it.
There was a problem hiding this comment.
The only remaining changes I'd recommend is to the getValue() section:
Ok, if String password = passwordField.getValue() should be avoided, then don't include it as an example (Lines 29-31). I'd then suggest moving the tip at the bottom of this section to where that getValue() snippet used to be and state that developers should transform the value before storing it.
| ## Placeholder text | ||
| ## Pattern matching | ||
|
|
||
| Applying a regular expression pattern to the `PasswordField` using the `setPattern()` method is strongly recommended. This allows you to enforce character rules and structural requirements, ensuring users create secure and compliant credentials. Pattern matching is especially useful when enforcing strong password rules, such as requiring a mix of uppercase and lowercase letters, numbers, and symbols. |
There was a problem hiding this comment.
[webforJ.BeDirect] Avoid using 'ensuring users'. Focus more on explicitly giving details about the feature.
|
|
||
| Applying a regular expression pattern to the `PasswordField` using the `setPattern()` method is strongly recommended. This allows you to enforce character rules and structural requirements, ensuring users create secure and compliant credentials. Pattern matching is especially useful when enforcing strong password rules, such as requiring a mix of uppercase and lowercase letters, numbers, and symbols. | ||
|
|
||
| The pattern must follow the syntax of a [JavaScript regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions), as interpreted by the browser. The `u` (Unicode) flag is used internally to ensure accurate validation across all Unicode code points. Do **not** include forward slashes (`/`) around the pattern. |
There was a problem hiding this comment.
[webforJ.BeDirect] Avoid using 'ensure accurate'. Focus more on explicitly giving details about the feature.
#49
#50
#51