Ticket Created
over 1 year ago

CIQQA-1662

Bug report: ConnectIQ Api & web request via GCM iOS is not passing http response as plain text

Hello ConnectIQ team,

I use makeWebRequest to proceed an auth process of an oAuth API, where I have to read an bearer token from the WebAPI.

The API responds the token as a JSON value type string. It's not possible to read that value as JSON dictionary. But with the GarminConnect app on a Android phone it's possible to use the parameter HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to get the http response as plain text to read the bearer token from.

With the GCM app on a iPhone it's not possible. The ConectIQ API returns error code -400 independent of the response type parameter.

As it's not possible to read JSON values from a application/json response body, it's necessary to be able to read the body as plain text and parse it in the app. That's the only possibility to handle WebAPIs not following the ConnectIQ rules.

Please add the possibility of reading plain text responses using the makeWebRequest parameter HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN on iOS platform like on Android.

Many thanks. That will help many developers dealing with WebAPIs which are not completely compatible to the ConnectIQ rules.

Referenze thead with examples:

https://forums.garmin.com/developer/connect-iq/f/discussion/310015/webrequest-how-to-ignore-wrong-response-content-type#pifragment-1298=2

Kind regards

Ronny Winkler

ronnywinkler
  • over 1 year ago

    One correction to my above post before I continue...

    I was reading the section of the document referring to the currently expected behavior. It looks like we want to allow the String/Number/Boolean JSON response to be accepted when the responseType is set to JSON. Unfortunately, those requirements have never been signed off by the various teams, so nobody is trying to implement them at this time. Additionally, if the mobile apps start to pass off JSON values, that is likely to cause the virtual machine to barf when it is expecting a JSON object. i.e., app crashes.

    But I won't host paid services for a free widget. It cost already enough time to develop and maintain it

    I hosted on AWS free tier for years and never paid a penny. I'm not sure how popular your app is, but the free tier allows quite a few requests before you have to pay.

    But if the SDK is focusing on the content typoe given in the response, wha is this parameter needed if I can't influence the result handling?

    You can't. The system (iOS) is focused on the response Content-Type and is not following the responseType that is part of the request. There is nothing you can do once the response has been received by the mobile device.

    As ConnectIQ if limited to JSON objects while there are many APIs using JSON string, numbers or something other, it's needed to get these responses into the widget as well.

    Yes, I understand your want for this to work. The API was written to expect a JSON object (Dictionary), not a JSON value (Dictionary, Array, Boolean, Number, Float, String) when you specify the responseType is JSON. That is just the limitation that it has based on that original design/implementation. Even if the mobile app was updated to allow JSON values, you'd still need new device firmware for this to work. Many device models are unlikely to be get a TVM update at this point. So if you intend to support such devices, it is a problem that will have to be dealt with outside of the mobile app and the device firmware.

    One solution would be to use the parameter Communications.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to force the SDK to provide the response body as plain text and the app can parse it as string.

    Yes, this is the Android hack that you're currently hoping will work solve your problem. A fix to the iOS app would allow this to work for iOS.

    Another aproach can be that the SDK will wrap simple JSON values into a JSON object like {body: "JSON string"}. Then the app can handle it as a regular JSON object.

    Yes, this would also work, but then the payload that we give is not the same as the payload that we receive. Developers would need to be aware of this and deal with it internally. Still better than not working at all, but not great.

  • over 1 year ago

    PS: Sorry for the typo. I can't edit the last post?!

  • over 1 year ago in reply to Travis.ConnectIQ

    Hi
    Thanks for the update.
    Yes I know I can do it using an external service. But I won't host paid services for a free widget. It cost already enough time to develop and maintain it :-)

    I can check the versions later. I habe an Android device where it works.
    I tested on a iOS device with the latest official Connect app from the app store.
    As SDK I used 4.1.5

    As I read the ConnectIQ manual, the options should define the expected content type. But if the SDK is focusing on the content typoe given in the response, wha is this parameter needed if I can't influence the result handling?
    As ConnectIQ if limited to JSON objects while there are many APIs using JSON string, numbers or something other, it's needed to get these responses into the widget as well.
    One solution would be to use the parameter Communications.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to force the SDK to provide the response body as plain text and the app can parse it as string.
    Another aproach can be that the SDK will wrap simple JSON values into a JSON object like {body: "JSON string"}. Then the app can handle it as a regular JSON object.

    It would be nice if can discuss in the development team. Many thanks in advance for your help.

    Kind regards
    Ronny

  • over 1 year ago

    -

    I don't know if or when it will get fixed. We have an internal document that lists out requirements for the behaviors given certain inputs, and as best I can tell it looks like the intent is that it would be forbidden for the responseType to be inconsistent with the response Content-Type header. I'm looking into this further, but that is what I'm reading.

    I've been asked to request the Connect and ConnectIQ app versions you are encountering the problem with. I'm assuming that is at least Connect 4.60.1, 4.61, 4.61.1, 4.62, 4.62.1, 4.62.2, and 4.62.3; ConnectIQ 2.19 and 2.20?

    As has been mentioned in other places, a possible workaround here is to use an intermediate service that will forward the request and then reformat the response as a JSON object. When I was developing apps, I successfully did this by propping up a small python service in AWS.

  • over 1 year ago

    Hello , hello ConnectIQ team,


    me and the users of the Homey Smarthome widget would love to get an update about the reported bug.
    It's acknowledget for months but still there is no fix or an comment/eta/timeline.

    This bug prevents all iOS user from authentication via oAuth2.

    Please fix it in the iOS Connect app. Pray
    Many thanks!