[DO NOT MERGE]

[Benmuiruri]

Description

Closed this PR after discussions and clarification of the feature in favor of a cleaner PR #9731

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[Benmuiruri]

Hi @garethbowen I worked on the first part to understand the API side routing and display the password page.
Now I'm updating the form to meet the Figma design and checking out the update password logic to use it in the password change form. As I do that, I'd like your input of my approach / understanding of this feature.

• The approach I would like to take for this is to edit the add user form in the admin to add a checkbox option, which is unchecked by default (hence false / null). When checked it sets require_password_change to true in the user object.
• In the login controller I have password_change_required = true;.
• The login controller will check the permission (does the user's role have the permission can_change_password_first_login && is require_password_change = true for the user && is password_change_required = true; ) - If all those are true, then it is the user's first time login and require password change.
• Once user changes password the password update function will be in the login controller so that it can update password_change_required = false; and possibly update user settings to update require_password_change flag to false That way subsequent logins will not require password change.

My Thoughts

• I believe this would work with CHT User Management tool to add the checkbox option when creating single or multiple users.
• I believe this would work if a user loses their phone because the admin can select the require_password_change checkbox in the admin.
• I believe this would not be a breaking change for existing users because require_password_change would be null for them.
• When making it mandatory for projects in future, we would make the require_password_change field to be mandatory true.
• A forgotten password feature would also reuse the same require_password_change in the user object.

[garethbowen]

The approach I would like to take for this is to edit the add user form in the admin to add a checkbox option, which is unchecked by default (hence false / null). When checked it sets require_password_change to true in the user object.

Unfortunately this does not solve the requirement. The requirement is that every time a password is set by anyone other than the user themselves (ie: admin), the user is required to set a new password on login. This should be enforced in the API somewhere to ensure this happens regardless of whether the password is set via the admin app, the user management app, or any other method. Therefore there must be no checkbox in the admin app to turn this off. You'll have to check how the user management app is written to make sure it applies there as well.

Because this may be disruptive we will include a feature flag to turn it off, just like we do for the new UX features like the action bar -> floating action button. In some time if/when this has been proven to work we will remove the feature flag and make this the only option for all user password setting.

All of this must default to true, otherwise we cannot claim the CHT is secure by default.

I believe this would work with CHT User Management tool to add the checkbox option when creating single or multiple users.

It's also possible to set up the user with scripts and so on, so I prefer the API approach so we can catch all cases where the password is set.

I believe this would work if a user loses their phone because the admin can select the require_password_change checkbox in the admin.

If the phone is lost then the administrator MUST change the password, not set the checkbox. You have to change the password in order to invalidate the session so anyone finding the phone is kicked out of the app. If they're changing the password then the process above (mandatory password reset) will mean you don't need the checkbox at all.

I believe this would not be a breaking change for existing users because require_password_change would be null for them.

Thanks for thinking about this! That's an absolute requirement.

[Benmuiruri]

Hi @latin-panda this is ready for an early review even though it is not 100% done. A couple of things:

• I tried a couple of things to display the param for the translation, but I could not get the minimum to display, any idea how to pass it from the js file to the html file ?
• I split the translation for login and password reset to api/src/public/login/auth-utils.js to avoid duplication. Do I change the eslint to allow compile app to run without the Parsing error: 'import' and 'export' may appear only with 'sourceType: module' error ?
• I'll work on the styling of the password reset validation user feedback to match Figma on Monday.

With those three points, I think the solution design is ready for an early review.

[latin-panda]

Nice job Ben! 🤩

Please test that password values don't appear in logs for weird error cases

[Benmuiruri]

Hi @garethbowen Thanks for your review.

• I refactored the auth-utils.js file to drop the use of modules
• I changed the updatePassword in the login controller to safe guard against timeouts over a network
• I added the currentPassword field in the password reset form
• I added a check for password reset in the authorization middleware

This video shows the progress so far

Screen.Recording.2024-11-18.at.10.45.46.mov

I'm currently updating failing e2e tests (almost done). As I continues, could I get your review of my implementation of your requested changes. Thanks

[garethbowen]

Great progress! I've left a few smallish things to work on.

It's now a fairly big change - once you make these changes and fix the tests I'll come back to it with fresh eyes and give it a thorough look.

[Benmuiruri]

Hey @jkuester 👋

With @garethbowen out of office this week, I was wondering if you could review this PR, we work together to get it merged.

I addressed the feedback, but I'd appreciate a fresh pair of eyes given it was my first time in the API side of things.

The PR description has a video of the state of the feature. Happy to work with you on this.

[jkuester]

👍 Sounds good @Benmuiruri. I can have a look at things and let you know if it would be helpful to sync on the details.

Unfortunately, I am pretty stacked up this week with PRs. I should be able to get to this by EOW, but if you need it sooner, feel free to replace me with a different reviewer.

[jkuester]

FYI, got dug in on this and started reviewing it today, but was not able to make it all the way through. I will be OOO on Fri/Mon, but will pick this back up next Tues. 👍

[Benmuiruri]

Thanks for the heads up @jkuester

[jkuester]

Alright, going to go ahead and post what I have reviewed so far. You have done a TON of great work here! (Hard to believe how much code it took to implement this feature... 😅 )

I have tried to focus just on important issues/questions and/or easy code suggestions. But, knowing the time constraints we have here, I will definitely accept "This works fine as it is" as a response to any of my refactoring comments!

[jkuester]

Okay, made it through the rest of the implementation code and unit tests.

For the e2e/integration tests, I don't like how all the random tests that need a non-admin user have to deal with the password change complexity. Ideally we would have dedicated tests for the password reset workflow and then none of the rest of the tests woud have to worry about it.

Now that is, of course, easier said than done. I guess the most naive way to avoid the password reset would be to add the roles to can_skip_password_change in config/default/app_settings.json, but that is not super elegant.

The main idea I have come up with so far involves updaing the createUsers function in utils/index.js to do either of these two things:

• Manually update the user doc after creating the user to remove the password_change_required field. This is nice and simple. The downside is that it is a bit artificial, but I am not sure it rises to the level of affecting the integrety of the tests.
• The other alternative would be to have the createUsers function write the initial user with with a different password than the one provided in the parameter. Then, after the user has been created the createUsers function could do a login and run the reset-password flow to set the password to the original password value provided for the user. The end result after calling createUsers would be that the user exists and has the specified password and a reset will not be triggered the next time the user logs in.

Ideally the deafult behavior of createUsers would result in the user existing in the db with the provided password and no password reset would happen the next time the user logs in. For the actual password-reset tests, we could either parameterize the createUsers function to be able to flag off that behavior (so the test can do the reset) or we could just not use this function for creating users for those tests...

[jkuester]

suggestion: can we also get a few tests to cover the new logic?

[Benmuiruri]

Closed this PR after discussions and clarification of the feature in favor of a cleaner PR #9731