Collect: ODK Collect crashes if server url starts with HTTP://

[hpardess]

I am using Collect v1.28.2.x and Android v10.

The latest update causes to break application and ODK collect fails to fetch the form from our application. We don't use SSL certificate (http://). Is SSL certificate must to use ODK Collect?

[lognaturel]

Sorry you're having this trouble! HTTP should still be supported. Can you please share the details of your server? Is it Aggregate?

[hpardess]

We are not using Aggregate but we developed our own platform and integrated ODK collect. Everything was working as expected since last two years but after release of v1.28.2, things are broken.

My API and aggregate API returns same xml response but I don't get list of blank forms from my API. The only difference i observe between both APIs is https protocol.

[lognaturel]

Do you implement the OpenRosa APIs? Those are the ones supported by Collect.

We did see some crash reports within code paths for deprecated APIs. I believed there has to be a malformed server response to trigger it (@seadowg might remember off the top of his head). If you could confirm whether you implement a non-OpenRosa API that would help us figure out the next step.

[lognaturel]

https://github.com/getodk/collect/issues/4126 is the related issue. It looks like the crash we're seeing would only happen if implementing a legacy API AND listing a form with no ID.

[lognaturel]

Closing for now because we don't know enough to troubleshoot. If you can give us more info on what API you are implementing and ideally give us access to a server that has this problem, please let us know!

[hpardess]

Here is the response of formList from my server but they are not listed in ODK Collect

And this is the demo URL provided by ODK and it lists the forms in odk Collect

Also my API is not public, it is restricted and I used DigestAuthenticationEntryPoint for authentication. I was working fine since last two years but it is not working after last release of ODK collect app.

[lognaturel]

Thanks for those screenshots. They illustrate why you are experiencing #4126: formId values are not specified for forms. Although formId is required, Collect was previously resilient to it not being there. As we have reduced redundancy between code paths it is now necessary.

All that said, the API you are implementing is not documented or supported. If you have come across documentation that describes it, please let us know. It was the API for Aggregate < 1 but was replaced by the OpenRosa formList API in 2009 or so. Aggregate still provides the old formList when not given a value for the X-OpenRosa-Version header but other systems should not implement it. We expect to remove Collect support for it soon.

Any information on where you found out about this API would be helpful as we manage the deprecation! I also highly encourage you to join the forum if you haven't already and follow the releases category to learn about betas and see what changes are upcoming in the tools that you use.

I see you also messaged me directly with some more information about your projects. Thanks for sharing and I know the community would love to learn more. The forum showcase is a good place for that and I'm happy to work with you on a post if you'd like.

[hpardess]

Once I was reading about API and shared it in following post:
https://forum.getodk.org/t/odk-survey-blank-forms-list-response/15131

ODK collect uses either xformList or formList url to fetch the blank forms from server. You can observe the response for bellow URLs
https://opendatakit.appspot.com/xformsList
https://opendatakit.appspot.com/formList

but in latest release of ODK Collect, both APIs works as expected and lists all blank forms while my API also return same xml but it is not listing blank forms.

[lognaturel]

Do you see how URLs in the formList response you link to include a formId query parameter? e.g. https://opendatakit.appspot.com/formXml? formId=v1.25-identify-user-track-changes-reasons Have you tried adding that?

But again, please be aware that Collect is unlikely to support that API for long. You should read and understand this documentation for the standards-compliant formList response. Aggregate is no longer under development and contains a lot of deprecated code so please go by the documentation rather than by the Aggregate implementation.

[hpardess]

Oh I got it... You mean the URL of each listed form must have formId query parameter.

[lognaturel]

As pointed out at https://github.com/getodk/collect/issues/4126#issuecomment-725554697 by @itlomd9 it doesn’t look like those URLs are actually parsed and there’s probably a formId element expected. The Aggregate response you see is never used so it’s not a model to follow.

The options I see are:

• implement the expected OpenRosa API. This is what I recommend. It will be required for future Collect versions.
• read through the Collect code to figure out where the formId was expected with the legacy API and implement that
• propose a PR to go back to prior behavior for the legacy API

It would be helpful to hear from both of you how you came to implement this API. Was it looking at the Aggregate response?