In Bahmni, we intend to keep the legacy ui module because it helps do simple things like adding users, identifier types etc. We are now working on implementing ability to change password for a user via the Bahmni UI. The webservices.rest api works fine.
However, problems arise if we want the admin to set the force-change password flag for a user. If this is set, my webservices.rest “/session” call to login a user goes through legacy ui’s ForcePasswordChangeFilter and sends back a response that is not easily parseable.
Changing password in itself has value, but it might be more effective if there is the ability to reset/expire passwords. Is there anything we can do to get around this issue?
This sounds like a bug that nobody has run into before because the legacy UI and refapp do not do the entire OpenMRS workflow via REST.
I guess the problem is that ForcePasswordChangeFilter is very high priority so it captures all the requests?
Can we change the legacyui module here so that if the request is a REST one (based on accept-type or something) it returns a REST-friendly response instead of forwarding to that other form?
And then we’d need to allow a user to update their own password in the webservices.rest module.
There is a long related discussion here: Unable to update user password via REST
@darius - Thanks for the link.
We will have to change the filter to also allow the password change request that can come in several forms (/session in the case of webservices.rest). We can potentially have the list of urls configurable. (Solution 1)
Additionally, it seems to me that the capability of admin force resetting password belongs just to the legacyui module - there is no mention of the “forcePassword” user property anywhere else within the core openmrs. Is this a functionality we wish to incorporate into openmrs-core (I think it is. )? In that case, we might have to think of a different design.
cc @burke, @wyclif from the other thread.
Yes. From this discussion, upon authentication the API would throw a
PasswordChangeException and the REST API would reflect this by returning a 302 Temporary Redirect to
/session with something like a “Password must be changed” error message and, presumably, a header or some other programmatically explicit indication that the password must be changed (e.g., a
Password-Change-Exception header set to
We do want the idea of users changing passwords to be a core part of OpenMRS. (Legacy UI used to be part of openmrs-core.)
The preferred fix is what Burke describes in his post.
You may need to do something a bit different, but still consistent with that approach, in order to make this work with currently-released versions of openmrs-core. (But if this is only relevant for Bahmni based on OpenMRS Platform 2.x, then I suggest introducing PasswordChangeException to the core API right now in Platform 2.0.2 before the Bahmni team releases it. I.e. we can treat “change password doesn’t work with REST” as a bug, and thus introduce the fix in a maintenance release.)
Hi @vinay, where are you at with this? As this been solved? (in 0.89 it does not seem to work)
@angshuonline, do you know if this works in Bahmni? ie, force-chaging the password of first login.
Unfortunately no. You can change password after you have logged in, but not like the way above.
@burke, I am not sure whether the webservices rest currently supports that or not.
(REST 18.104.22.168e371e, Core - 2.1.1).
Right now, it is sending 200 Ok with the response body containing the HTML ("The administrators have requested that you … "). Changing the “accept” header to “application/json” throws error.
If OpenMRS were to send 302 when we try to login (which btw is a GET request, not a POST), then we could inspect the redirect url and throw up the correct page on Bahmni (which is already there for change password).