Authenticated web/json requests

I don't know of a reason why this shouldn't work, so I've reported it for investigation. Apologies for the trouble--I'll report back here once I know more. Thanks!

Hi Brandon, thanks, appreciate it!

Any update on this? I see the same thing - va on FW 3.00, CIQ 1.1.2

This is on the books to be investigated and fixed, but is still in the back log. I believe that POST may be required for authenticated requests to be fully and properly supported, and there's already been work to get that added (it hasn't be made available in a release version of CIQ yet). So, we've made some progress, but nothing that has been released at this time. I can't provide any definite estimates, but my feeling is that this should be available later this year.

Support for userinfo in an http uri is a violation of RFC 1783 (the Uniform Resource Locators specification). Here is a quote from that document.

3.3. HTTP

The HTTP URL scheme is used to designate Internet resources
accessible using HTTP (HyperText Transfer Protocol).

The HTTP protocol is specified elsewhere. This specification only
describes the syntax of HTTP URLs.

An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed. <path> is an HTTP selector, and <searchpart> is a query
string. The <path> is optional, as is the <searchpart> and its
preceding "?". If neither <path> nor <searchpart> is present, the "/"
may also be omitted.

Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.

That document was superseded by RFC 3986, which has the following to say about the use of userinfo in any url (not just http urls).

3.2.1. User Information

The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource. The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.

userinfo = *( unreserved / pct-encoded / sub-delims / ":" )

Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.

Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).

Additionally, RFC 2616 (the HTTP 1.1 specification) and its predecessor RFC 1945 (the HTTP 0.9/1.0 specification) make no mention of userinfo, as the http protocol has its own authentication scheme using the WWW-Authenticate header (as described in RFC 2617).

While this may work, this is apparently non-standard behavior for the http protocol and is a documented security issue.

I don't have the appropriate tools setup here, but a network traffic monitor (wireshark, netmon) or a simple http proxy should be able to show you the http request and response sent out by the phone/simulator. This might help to track down where the error is occurring.

Travis

I don't have the appropriate tools setup here, but a network traffic monitor (wireshark, netmon) or a simple http proxy should be able to show you the http request and response sent out by the phone/simulator. This might help to track down where the error is occurring.

Travis

Maybe the Garmin folks will do it.. I spent too many years watching X25, 3270, and IP packets on a sniffer! :)

As I control the server my CIQ app is talking to, I just had to give a perl script a weird name and put it in an odd spot, and do the same with an HTML file. Not much of a security risk with the html, as it's a list of the status of lights, etc in my house, and if you just drive the house, you'd know that! the Perl script controls these lights, but you'd have to know the values for the parameters, and worst case, you could turn one of the lights! ( :) )

(Home Automation on your wrist!)

If all of this is true, then why do you need use url authentication like this? Why can't you just update your perl scripts to accept the username/password as query parameters? You don't seem to mind sending them in clear text, so why does it matter what end of the request they come in. Honestly, you don't need to send the username/password at all.

Travis

It's simple Travis - in this case I control the server - in the next project I want to do, I don't, and will need to use a userid/password.