Metadata sharing module doesn't seem to handle reverse proxy headers

Development
1

Hi everyone,

@ball brought to my attention that mdsbuilder has a bug.

If you try to go to:

Admin -> Metadata Sharing / Export Metadata -> Create package -> next -> Add metadata to package -> Concept (Choose Individually) -> Pick any concept -> Save

Nothing will happen.

In network, you can see a xhr request to ‘https://mdsbuilder.openmrs.org/openmrs/module/metadatasharing/export/selectItems.form?type=Concept’, which returned 302 to ‘http://mdsbuilder.openmrs.org/openmrs/module/metadatasharing/export/edit.form’ (note the protocol change from https to http).

It’s a little bit weird to see an ajax request returning 302, but :woman_shrugging:

The browser then blocks it:

Blocked loading mixed active content “http://mdsbuilder.openmrs.org/openmrs/module/metadatasharing/export/edit.form”

OpenMRS is running as a docker container. The image is created using our SDK and a configuration file and pushed to docker hub.

In front of docker, I have an nginx (to offload from https to http), but I’m adding the headers:

    proxy_set_header HOST $host;
    proxy_set_header  X-Forwarded-Proto $scheme;

This has always been enough to all other applications (I don’t think I’ve had problems with refapp).

Can someone with more java knowledge please investigate why that module is completely ignoring that configuration? That doesn’t seem to happen anywhere else.

I really have no way of debugging this.

2

@cintiadr , has this been the behaviour before ? or its a bug after the modules upgrade i tried . In otherwords was the module functioning properly before the upgrade ? cc @ball

3

This may be a clue.

4

Should have mentioned. This was happening before the latest upgrade. We waited for the upgrade to happen to see if the problem would go away.

No idea since when it started happening. Sometimes it’s because browsers just become more strict.

5

One more clue – this function works properly (“save” button works) for my other implementations. Maybe something specific for this config and docker?

6

So, what I know is that the offending redirect (WebUtils.redirect) is somehow being blocked by the browsers as it’s considered active mixed content. That seems to be the default behaviour since 2013, so it’s not a new behaviour.

Note that I haven’t yet seen any of the refapp docker containers suffer from that problem. All I had to do was to actually add a couple more headers (1 and 2). See current configuration here.

@ball do you have any idea when was the last time it was working fine?

Yeah, I’ve seen several pages with recommendation for springboot applications, but it’s not what we have.

7

I just did the following test:

  • disable http->https redirect for uat-refapp (and tested it)
  • logged to uat-refapp and started running a bunch of tests

Everything seems to work, except exporting a concept in a metadata. 45%20pm

I don’t know exactly what’s wrong, but it seems to me that the problem is very localised to this module/action.

8

Scratch that.

Talking about reference application, all our containers are returning http instead of https when doing a 302:

$ curl -v https://uat-refapp.openmrs.org/openmrs
< HTTP/1.1 302 Found
< Location: http://uat-refapp.openmrs.org/openmrs/
$ curl -v https://uat-refapp.openmrs.org/openmrs/
< HTTP/1.1 302 Found
< Location: http://uat-refapp.openmrs.org/openmrs/login.htm

Same for demo or any other.

I think the browser is just being helpful and using https if it’s not ajax.

You can see the docker files that are generated by the SDK here

9

@ball do you have any idea when was the last time it was working fine?

This isn’t new. 6+ months? My other workaround has been a local SDK sourced with the latest CIEL dictionary, but this doesn’t help with community.