Internal server error when downloading encrypted forms

User Support Data Management
, , ,
25

Thanks for your response and the clarifications!

  • About what seems to be a “misconfiguration for years”, I don’t know at all. But since the error message is an HTTP 403 “Forbidden” error (for v1.17+) or an HTTP 502 “Bad gateway” error (v1.16) and since it does not happen with ODK central, this is the only idea I can come up with. And it has first appeared with version 1.16.0, which was released years ago.

  • The focus on version 1.15 of ODK Briefcase finds its justification in that it has been the latest version able to download encrypted data (although it was not always able to decrypt and export it) from kc.humanitarianresponse.info. All later versions are unable to pull the encrypted collected data from that server (see previous bullet point), whereas they smoothly pull it from ODK servers. So when very sensitive data has been at stake for the last 2-3 years, we have been many people relying on v1.15 (and it was already quite hard for a simple user like me to figure out that downgrading to v1.15 was the solution).

  • Now we cannot rely on v1.15 any longer since it now crashes when pulling data from a form having an external CSV instance (whether the form is encrypted or not). Later versions can handle those CSV instances, but as said above, cannot pull encrypted data. I suppose this new problem comes from a legitimate update of KoBo’s server, but users are now left with a hard choice: either CSV instances but no encryption (and latest versions of Briefcase are fine), or encryption, which implies v1.15 or lower (at least for data pulling), which forbids CSV instances.

  • As you may see in the GitHub conversation that you point, I discussed that issue with lognaturel. Then, she gave me temporary access to a public testing ODK server, where we could verify that the problem did not seem to come from ODK Briefcase. In that same conversation, she concludes:

It seems Kobo makes some kind of assumption that Briefcase was accidentally meeting previously but stopped meeting after v1.15.0. Two possible next steps for someone who needs this fixed would be to contact Kobo support and have them look at compatibility with more recent Briefcase versions and/or do a git bisect on Briefcase to track down which commit introduced the change that caused an incompatibility with Kobo.

I did the first half and reported here at the time that v1.15.0 was the last to work (v1.16.0-beta0 does not allow to connect to KoBo server in a way that would allow to start a data pulling, and v1.16.0 is already unable to pull encrypted data), but it seems it didn’t trigger visible investigations, For the second half, I unfortunately have neither the time -like basically everybody, which is a shame-, nor the skills to track down in which commit the bug first appeared. If you think that would be an immense help, though, I will consider spending a few hours learning what a git bisect is and how to do it, and try my luck some day in the next months.

I must say I struggle to understand what and who is behind KoBo, ODK and the myriad of projects like XForm, XLSForm, Javarosa, Enketo etc., how it is run and the limitations or constraints on all that ecosystem. I don’t even understand what KoBo is in relation to ODK, as I initially thought KoBo was just maintaining a public (and re-faced) ODK Central instance, which obviously proved wrong.

Cheers

1 Like