Could not access the module download URL with Angular GET request

suthagar23 · August 29, 2017, 9:24am

@darius Yah, here It is using the Modulus URL for the update. It might be a huge problem while we retire the modulus from the live

But I have developed the SysAdmin OWA to update the module with OpenMRS Addons URL (mostly with bintary end point) - I have developed an algorithm to update the module in the SysAdmin OWA

Here I want to just give the module Package and current version
It will check the module package with OpenMRS Addons REST endpoint
Compare the latest version with the current version. If the latest version found then indicate the update status
If the user wishes to update, then download the module .omod file using REST GET requests and upload it to the server using ModuleAction REST resource.

reubenv · August 29, 2017, 11:06am

@suthagar23 You might also want to check whether the latest version will be compatible with the user’s core version too.

suthagar23 · August 29, 2017, 11:14am

@reubenv anyway when I upload the module, It will be checked by the moduleFactory. if it’s not compatible with the core version, then moduleFactory will throw the error. Then I can catch it from the OWA to indicate the user about the problem.

suthagar23 · September 2, 2017, 6:36pm

Hi All,

Now, I am able to update and download modules from Bintary.com using the Server Side download calls

Modifications

Implemented new Action Called “UPDATE” with field “downloadUrls” in the REST Web services ModuleActionResource1_8 to achieve the module update
Unfortunately, OpenMRS Core (ModuleFactory Class) doesn’t have any methods to download the module directly from URL. So I wanted to implement that method to achieve the task. Anyway, If I implement this method in OpenMRS Core, then definitely SysAdmin OWA will require the newer version of the OpenMRS Core. To avoid that problem, I implemented that simple logic in the REST Web services ModuleFactoryWrapper it self and created Action called “LOADFROMURL” to perform this action.

CC : @dkayiwa

darius · September 2, 2017, 7:14pm

I would be concerned about the security implications of letting the user provide the URL here. Doesn’t the module already say where we should check for updates, in its config.XML file?

I would expect that we just want to how did the owa ask the server update module XYZ to its latest version. The server, and or the module Repository, are responsible for deciding what version that is.

-Darius (by phone)

darius · September 3, 2017, 12:51am

To clarify: security isn’t really the issue (because any user who can manage modules must have a very high privilege level).

As a consumer of a REST API, what I would expect to see is to easily be able to ask:

(GET) are upgrades available for module(s)?
(POST) upgrade module X to latest version

or, upgrade module X to version Y

But in terms of the module management REST API, having to say “replace module X with the thing you download from URL Y” doesn’t make sense as an API definition.

suthagar23 · September 4, 2017, 3:12am

@darius I will check the REST Calls and update functionality with your idea.

Anyway, the module update file contains the URL from modules. But I am checking with AddOns through the OWA.

Actually, I am following this way to check the module update from add-ons.

Get the latest version of the module from AddOns using REST Call
Check the latest version and installed version of the module
If the module has newer version, then get the Module Download URL using the REST Call to AddOns
Update the module download URL using the internal REST Call to server Web Services module
Call the server side Update REST Call

So I preferred this way to update the Module

darius · September 5, 2017, 8:41pm

@suthagar23, just to be explicit, this is how I was thinking thing should work:

A module defines an updateURL in its config.xml. Example: https://github.com/openmrs/openmrs-module-xforms/blob/4.3.11/omod/src/main/resources/config.xml#L18
If a user wants to upgrade their xforms module:

the OpenMRS server should query https://modules.openmrs.org/modules/download/xforms/update.rdf, which returns a list of module versions, each also describing the requireOpenMRSVersion
the server decides on the highest supported module version for their openmrs-core version
the server downloads it
the server installs it, restarts the spring context, etc.

I’m not actually suggesting that you rewrite everything now. But FYI (and also FYI @dkayiwa and @burke) there was some previous design (a module declaring its updateURL) that we are no longer respecting in the new Manage Modules OWA.

darius · September 5, 2017, 9:23pm

(Reuben pointed out that I was not as clear as I thought I was being…)

The design point is that:

the module declares where you’re supposed to check for updates.
the OpenMRS application should trust it, not override this because “we know” that the url it gives is wrong.
it’s bad style for us to “support” this feature (a module declaring its update url) but then ignore it, in a way that someone looking at the openmrs-core codebase would have no way to know about.

As a result, we (people working on Add On Index, and the Infra team) need to ensure that the relevant update URLs keep working even after we retire Modulus and replace it completely with AddOns.

suthagar23 · September 8, 2017, 4:43pm

There are no functions in Core (ModuleFactory or ModuleUtil) to find the update for single Modules. There was a function to check update for all modules.

github.com

openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/module/ModuleUtil.java#L775


	 *
	 * @return True if an update was found for one of the modules, false if none were found
	 * @throws ModuleException
	 */
	public static Boolean checkForModuleUpdates() throws ModuleException {
		
		Boolean updateFound = false;
		
		for (Module mod : ModuleFactory.getLoadedModules()) {
			String updateURL = mod.getUpdateURL();
			if (StringUtils.isNotEmpty(updateURL)) {
				try {
					// get the contents pointed to by the url
					URL url = new URL(updateURL);
					if (!url.toString().endsWith(ModuleConstants.UPDATE_FILE_NAME)) {
						log.warn("Illegal url: " + url);
						continue;
					}
					String content = getURL(url);
					
					// skip empty or invalid updates

This ModuleUtil - CheckForModuleUpdates function will check the updates for all modules and set download URL value to the modules which have the updates and set null to download URL to modules which haven’t the updates.
Then I want to call the update function from ModuleFactory to download the module update (one call for each module update)

So I wanted to perform this actions from the OWA level (I can’t change core for this purpose),

Call the ModuleUtil - CheckForModuleUpdates function via the rest(It will set the download URL to the modules which have updates)
Iterate all the modules in the OWA level and check for the module download URL (If the download URL contains value then show that modules in the update list).
If user click the update button, then call the ModuleFactory - Update function via the REST to update the module
Then Call again ModuleUtil - CheckForModuleUpdates function to set the download URL as null (I can’t set the module URL as null)

Blocker: Using this way, I can’t check update for one Module.

That’s why I tried to set the module download URL and achieve the updates (here I can use the AddOns URL for all modules)

@darius and @dkayiwa What will be the possible solution for this scenario?

darius · September 8, 2017, 11:04pm

Personally I would not try to do this without changing OpenMRS core. Instead we would use this as an opportunity to refactor core so that it has a better module management API.

I should also point out that reloading the spring context (which happens each time we do a module management operation) is expensive, and if you do it too many times you run out of memory. (Actually, maybe this is fixed in Java 8: do we know this?) If I were designing with that in mind I would have the UI flow be: 1. Check for available updates to all modules, 2. Present a list of available updates with checkboxes or similar, 3. User indicates which updates to apply, 4. Download all of them, load them in one go (and restart the spring context one time only).

-Darius (by phone)