Authenticated web/json requests

I'm surprised that a platform that can control devices in your home would want your username/password being sent in plain text. Most all web services for this stuff take an access token that is only sufficient to access a small part of the API functionality, or they use regular http authorization along with https to secure that data.

Note: Provided that the request is sent over https, it should be encrypted so security of the user credentials is not the real concern here.

So Travis, what would you suggest that would work with a makeJsonRequest() in CIQ?

My suggestion would be for you to stop requesting makeJsonRequest() support behavior that violates the http specification.

You seem like to criticize how I'm doing things, but offer no alternatives. Any kind of a token in the URL would be plain text too..

Sure. But the solution to that problem is simple- you use https. That will cause the entire http request, headers, and message body to be encrypted.

Of course https protects the username and password that are passed along in the url, but as I said above, userinfo support in an http/https uri is non-standard. It may work with some browsers and some servers, but it is not supposed to and it doesn't make sense to add it to something like ConnectIQ.

And the server in this case is on the same lan as the wifi router, so 99.9% of the times a request is sent, it never even hits the internet.

It sounds like the request would be routed over the internet if you aren't within reach of your home wireless network. If this is the case, 99.9% is only valid if you use this from home 99.9% of the time. Even if one request was routed over the internet, that is still a security concern.

What's the worse that can happen? My kitchen light goes on when I don't want it? :)

Services similar to this offer the ability to control a lot more than your kitchen lights. Oftentimes home automation networks provide controls for garage doors and door locks. Exposing the ability for control these devices would be a significant security concern, would it not? See next paragraph...

As mentioned above, using https does protect the entire http request. This should be sufficient to protect user credentials from being leaked regardless of how they are provided. Regardless of the method used to transmit the credentials, this should protect them from being sniffed off of the wire. My previous statement about the security of the data in my previous post is moot.

The matter that remains is the passing of the user credentials via the userinfo field of the uri, which is still a violation. ConnectIQ already supports sending query parameters. It seems reasonable to request the ability to specify additional http headers or just the ability to provide a username/password to be stuffed into an appropriate authorization header.

If the userinfo in the uri is the only way that the service you are using supports user credentials, then it seems reasonable to request that they update their web service api to handle requests that conform to the http specification.

If I'm home and controlling the lights in my house, yes, 99.9% of the time it's used will be on the home network. But without even plain test user/password, it's open to the outside world with no security at all!

You don't have to instruct me in home automation - I've been doing it since the 1980s! (when X10 was still called BSR!)

And it works in CIQ (the simulator). Just not on a real device - that's why I think the issue is with GCM.
------
Travis - you do understand that "RFC" is not a defined spec, right? It's a "Request for Comment" and changes whenever another RFC succeeds it, and can be ignored by anyone the uses the RFC it superceeds! Someone can have an RFC that says "this is depreciated", but that can just be ignored by people that use it.

The reality is, I can not find any current browser that can't handle "xxx://user:password@website" with xxx being http or https, and websites I've found that need userid/password, the server also handles it... And the ciq simulator handles it too - just not on a real device!

How would you like to see CIQ changed to handle accessing site that need a userid and password, in a common way that didn't involve keys or tokens. as you don't want to see makeJsonRequest() changed??

Looking forward to when ConnectIQ adds some options to makeJsonRequest (i.e. PUT/POST, Headers would be great).

To be honest as an iOS/Android dev I don't really see why this hasn't been added to a the Garmin connect clients already as it seems an easy addition and from the Connect IQ client only requires the passing of the options dictionary to the connect client acting as the proxy call.

options (Dictionary) — Dictionary of options. Can be null. makeJsonRequest does not currently support any options. Future options are TBD.

Surely we just need a Dictionary with these 2 options

Method : "PUT/POST/GET" (Default Get)
Headers : Dictionary of Field,Values (i.e. "Authorization","Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==")

As soon as this is available I can have a Hue Light widget and I'm sure with the above implemented, thousands of other useful widgets could be created!

Edit: Spelling

!

Thanks for you comments! We're aware of the interest in this see the need for these features. Some of these things are on the road map to be added, so expect to see it in a future release. I haven't shared many details so far because, while we're working on it and see the need for these features, I didn't want to set any expectations. 😊

Hi, sorry for bumping an old thread but I just stumbled upon this problem.

It works to specify http://user:[email protected] using the simulator but as soon as I do it on the watch, I see that I get HTTP 401 in the logs of my web server.
I tried to embed the user:password (base64 encoded) in the http header Authorization: Basic. But instead, that caused the Connect application on my phone to crash.
What is the latest news on this subject?