Skip to content
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

Improve UX for setting new password in webform #32

Open
aputtu opened this issue Nov 30, 2023 · 3 comments
Open

Improve UX for setting new password in webform #32

aputtu opened this issue Nov 30, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@aputtu
Copy link

aputtu commented Nov 30, 2023

Some issues in user experience when setting password at https://sid.erda.dk/cgi-sid/reqoid.py :

  1. When signing up (test done as an external ERDA user), the webform checks whether password conforms to length, but not if characters are valid. User is only informed about invalid characters after pressing "Send" button, and input arguments gets rejected.
  2. When setting weak password, the form does not complain, but a pop-up message display on submit:

Please provide a valid and sufficiently strong password.
I.e. 12 to 256 characters from at least 1 of the 4 different character classes: lowercase, uppercase, digits, other.

  1. Even when user is informed that password looks good, they may get told afterwards submitting, that password contains invalid characters.
  2. The error message displays less/greater than character (<>) in html.
  3. Double display of error message when passwords are identical is correct handling from server-side, but may confuse more than necessary, assuming non-identical passwords are given separate error message.

The error message:

input parsing error: password: ****************************************: found invalid character: u'$' (allowed: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 -_#.,:;!@%/()[]{}+=?&lt;&gt;)

input parsing error: verifypassword: ****************************************: found invalid character: u'$' (allowed: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 -_#.,:;!@%/()[]{}+=?&lt;&gt;)

Input arguments were rejected - not allowed for this script!

Steps to reproduce re: invalid characters:**

  1. Go to signup page and set password with illegal character, but otherwise conforming to webform criterias
  2. Click "Send" button

Steps to reproduce re: weak password

  1. Go to signup, fill out form, but use only "123"/"123" as passwords
  2. Click "Send" button

Suggestions for improving user experience:

  • Use info sign (?) what when clicked, displays required inputs upfront:

Please provide a valid and sufficiently strong password.
I.e. 12 to 256 characters from at least 1 of the 4 different character classes: lowercase, uppercase, digits, other.

  • Extend to check also for usage of invalid characters in webform
    • This way user will get warned while typing/setting pw, and see fewer error messages.
  • Extend to check for weak password while typing
  • Make error message more readable if user somehow still slips by check; e.g.:
    • On webpage error message could be rewritten into:
      Password contains characters that is not allowed.
      The input argument was rejected.

      We allow the following characters: a-z, A-Z, 0-9 and -_#.,:;!@%/()[]{}+=?<>

@jonasbardino jonasbardino added the enhancement New feature or request label Dec 1, 2023
@jonasbardino
Copy link
Contributor

Thanks, valid points and suggestions.
The validation on the form page is pure HTML5 using regular expression patterns, which makes it unrealistic to cover all corners for complete verification. E.g. checking for dictionary words or simple patterns like 12345678 will generally need the python backend.
The input errors come from our standard safeinput validation helpers, which are unaware of the specific context.

In short, polish is possible but not trivial.

@aputtu
Copy link
Author

aputtu commented Jun 12, 2024

Bug report in internal ticket #33041 points out that "<>" characters likely are using wrong encoding. The characters gets displayed incorrectly, when a password containing a non-allowed character gets rejected; displaying the allowed characters.

@aputtu aputtu closed this as completed Jun 12, 2024
@aputtu aputtu reopened this Jun 12, 2024
@jonasbardino
Copy link
Contributor

True, everything in that string currently gets html-encoded to prevent illegal characters being injected in our html and potentially causing XSS attack vectors.
Not sure how much work it would require to only encode the actual invalid char(s).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants