Skip to content

Conversation

@jlledom
Copy link
Owner

@jlledom jlledom commented Jan 9, 2026

What this PR does / why we need it:

Currently, a provider can enforce strong password for the developer portal, and weak passwords are accepted by default. About admin portal, there's no option to enable strong passwords, weak passwords are always accepted.

I think both situations make no sense. I don't think it's acceptable to allow users decide whether they enforce strong passwords or not, as long as strong passwords are possible, that should be the default. And same thing about admin portal.

In this PR, I remove any option to accept weak passwords in both admin or developer portals. Existing passwords will continue to work, but new passwords will be enforced to be strong. Also, I increased the minimal number of characters to 16.

This affects multiple screens, but also API endpoints, this is the complete list:

  • All scenarios with a password
    • Admin portal
      • UI
        • User invitation signup form
        • Personal details
        • Edit user
        • Forgot password
      • API
        • POST /master/api/providers.xml
        • POST /admin/api/users.xml
        • PUT /admin/api/users/{id}.xml
    • Developer portal
      • UI
        • New buyer signup form
        • Existing buyer user invitation signup form
        • Personal details
        • Edit user
        • Forgot password
      • API
        • POST /admin/api/signup.xml
        • POST /admin/api/accounts/{id}/users.xml
        • PUT /admin/api/accounts/{id}/users/{id}.xml

Besides, while doing this, I found a few UI errors that I told Claude to fix. This are the affected screens:

  • Admin portal
    • User invitation signup form
      • JS validation:
        • Before: min 6 characters
        • Now: Same restrictions as in backend
      • Error messages formatting
        • "\n" was literally printed instead of a new line.
    • Personal Details
      • Password input in clear text
    • Edit user
      • Password inputs visible for users without password (e.g. OAuth)
    • Create new buyer
      • Password input in clear text
    • Forgot password
      • Pass JS Validation: Sames as above

Another thing I noticed is strong passwords, even when enabled, were not being enforced for users not created by a human. For instance, the default admin user created when a buyer is created was always accepting weak passwords no matter the setting. I also fixed this.

Which issue(s) this PR fixes

https://issues.redhat.com/browse/THREESCALE-8916

Verification steps

You can go through any (ideally all) screens above an try to set a weak password. Also tests should pass.

@jlledom jlledom self-assigned this Jan 9, 2026
@jlledom jlledom force-pushed the THREESCALE-8916-admin-strong-paswords branch from 8c93fc8 to da18ea7 Compare January 9, 2026 14:04
@jlledom jlledom changed the title Threescale 8916 admin strong paswords Threescale 8916: Make strong passwords mandatory Jan 9, 2026
@jlledom jlledom changed the title Threescale 8916: Make strong passwords mandatory THREESCALE-8916: Make strong passwords mandatory Jan 9, 2026
@jlledom jlledom force-pushed the THREESCALE-8916-admin-strong-paswords branch from da18ea7 to 5b00c7f Compare January 9, 2026 14:14
jlledom and others added 11 commits January 12, 2026 16:57
For both provider and buyer users
Co-authored-by: Claude <noreply@anthropic.com>
It was actually showing "\n" in flash errors

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
It's fine to leave the password nil when there's an open_id set
Use strong passwords in tests
@jlledom jlledom force-pushed the THREESCALE-8916-admin-strong-paswords branch from 33fe198 to 25f4a95 Compare January 13, 2026 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants