Sorry I missed this when I was on leave. Someone just complained about it again and I noticed.
In the openmrs-core code that calls this, we’re using a custom implementation of “HttpClient” that calls java.net.URL.openConnection() and its javadoc doesn’t specify whether this will follow redirects or not. [10 minutes later] I tested this and it seems like it does not follow redirects…
I’m comfortable with the approach of making Cintia’s job easier by allowing the infra team to put a redirect in place for this, and we’ll need to fix this in some openmrs-core maintenance releases. (I only say this because it seems to be a pretty rarely-used feature, if it has been broken since October and nobody has said anything…)
Simply deploy Implementiation ID to a different domain, e.g. implementation.openmrs.org, and core is changed to use the new ID.
I configure our proxy/CDN to proxy all /tools/* requests this new domain, so it will be transparent (and no redirect).
I’m quite happy to implement #2 if that make users’ jobs easier.
What I’m a little bit worried is that the URL you sent is actually http, not https.
Assuming we have the passphrase transmitted over the network, that doesn’t seem ideal.
I suppose even with option #2, it would be better to change the URL to use https straightaway.
It would be nice to fix the http/https security issue while we’re at this. Unfortunately that means that we’d still need to make a change in openmrs-core.
@aramirez, you are the one who specifically ran into this problem, so let’s get your input. Do you need implementation id to be working before your upgrade to 2.x or is it enough to have it work after?
If you need it to work before upgrading to 2.x, would it be straightforward to upgrade all of your servers that need to connect to the implementation id server to the latest in their release line (I guess a new 1.9.13 release, if I remember what you’re running)?
@cintiadr, if Alejandro needs his existing servers to be able to connect without an upgrade then I guess we should do #2 and skip the https fix. But if he does not have this requirement, then I would lean towards #1 plus the https fix.
@darius@cintiadr Ideally before upgrading to 2.X as migrating my whole system to 2.X for now is only contemplated if the new sync module works properly.
So, @cintiadr, I think we can do your first proposal (deploy to implementation.openmrs.org) and change openmrs-core, and also switch this to https-only.
(@dkayiwa can you help me remember to create a ticket for this in openmrs-core once Cintia confirms how she’ll do this? Actually I think we should code in the expectation of a redirect, e.g. we hardcode “om.rs/implementationid” instead of the actual tool URL. Or maybe this is not necessary since the Infra team can redirect with a one-liner…)
You might not want to use om.rs, as it would be a redirect (301/302), and apparently your code doesn’t follow redirects…
The thing is that my backlog is currently out of control (:D) and for sure I won’t be able to touch it in less than a month. If anyone else could do the dockerisation part, I could deploy it earlier.
Apparently I had stopped watching this talk category, or maybe I just missed some emails. Anyway, just seeing this now.
I think we agreed earlier that it’s okay to require the dev team to upgrade the openmrs core code to handle redirects.
It is what it is!
@jose007, Is there a post on some other topic that gives more details about the problem you ran into? This module’s latest commit was in 2014, so I don’t expect any devs to be actively involved with it, but if you share your error message (on a new post), or point me to where you already did this, I can peek at the code and advise on how to go forward.