Indigo Domotics

the username:password convention is only for HTTP Basic Authentication - which we don't support out of the box because it displays your password in plain text over unencrypted network connections. Indigo uses HTTP Digest Authentication.

Dave is correct - your client must support Digest Authentication or you must switch the authentication on your server to basic (which we REALLY don't recommend).

mark_anderson_us wrote:

So, I got some basic stuff working with devices using Angular.

I created the following Angular "objects"

• DeviceService (factory pattern) - Gets a list of devices or a named devices detailsMain controller
• Main layout - has header, footer, etc, and "slots in" content based on which route (controller) is chosen
• Main Controller - specifies routes (controller and templates)
• DeviceListController - Gets list of devices using DeviceService
• DeviceController - Gets device details when clicking a device, using DeviceService

Things are looking good.

Regards

Mark

Hey Mark,
Can you share your code for how you were able to get Digest Auth working with CORS using Indigo in Angular? I assume its in angular 1.x?

I'm making a similar project in Angular2 and am having some issues. There are no good examples that I can find to do digest auth in Angular2, so I am piecing together my own solution, using the guts from https://www.npmjs.com/package/request-digest. I've replaced the node package 'crypto', which is only available in the node server/backend and is not available in the browser, with CryptoJS which has a typescript definition from DefinitelyTyped. In order to get access to the digest nonce challenge to compute a proper response, I had to add another header (in addition to Access-Control-Allow-Origin = '*') which is Access-Control-Expose-Header = 'WWW-Authenticate'. With those headers added to Indigo's cherrypy config, I can now see the WWW-Authenticate response header from my first unauthorized request attempt. When I compute the Authentication header for the digest response and attempt to make a second request with that header, I see in Chrome dev tools that it triggers an OPTIONS pre-flight request, which does not and should not contain auth headers, but this OPTIONS request gets denied with the same 401 Unauthorized response.

It seems the pre-flight OPTIONS request requires auth from the Indigo server and this goes against the CORS spec, which states that OPTIONS requests should not require credentials. As noted here http://stackoverflow.com/questions/38326128/xmlhttprequest-cannot-load-response-for-preflight-has-invalid-http-status-c

Any examples you could provide from an angular 1.x solution might be useful in getting the same thing to work with my current angular2 implementation.

Thanks!
Matt

Hi jay

I abandoned this a long time ago as it was clear it wasn;t going to work. Bought RTI instead

Hi Jay and Mark,

have there been any updates on this. I'd really like to get it working, but im still getting the 401 return after adding the "cherrypy.response.headers['Access-Control-Allow-Origin'] = '*'" in the designated file.

Have there been updates, as Mark said after your input on this, that he got it working, but eventually abandoned it.

Are there any other tips we can follow?

No, we're not looking into it at the moment. Pretty low on the priority list.

henkjanvries wrote:

Hi Jay and Mark,

have there been any updates on this. I'd really like to get it working, but im still getting the 401 return after adding the "cherrypy.response.headers['Access-Control-Allow-Origin'] = '*'" in the designated file.

Have there been updates, as Mark said after your input on this, that he got it working, but eventually abandoned it.

Are there any other tips we can follow?

I plan to get Indigo's cherrypy CORS enabled for my project. I just haven't touched it in awhile. I'll reply on this thread when I get back to it.

Cheers!
Matt

We got it working, i was editing the wron python file (indigo 6 in stead of 7 )

So we can now actually hit the server with commands.

We are now starting to build a framework to create something like this



Keep you posted

Cool, look forward to seeing your progress.

HI Jay

Is there a library where we can find ALL the command within the API?
Not just that is available in the example page, but every command known to Indigo.

Secondly, is there a way to do a call for all urls of every device/action group/trigger/schedule/variable so we have all of them?

thanks!

henkjanvries wrote:

Is there a library where we can find ALL the command within the API?
Not just that is available in the example page, but every command known to Indigo.

Not really, just the docs. Pretty sure the REST docs are up to date, but I could be wrong.

henkjanvries wrote:

Secondly, is there a way to do a call for all urls of every device/action group/trigger/schedule/variable so we have all of them?

Not for the current REST API.

Ill just keep posting my questions here.

there is alot of data available via de the wunderground plugin. But when running the api device call for a wunderground device, i dont get all the info.

Is there a way to get the custom data, because that data is visible in the indigo app for ios.

henkjanvries wrote:

Is there a way to get the custom data, because that data is visible in the indigo app for ios.

No - as we've discussed on other threads, the REST API predates the IOM and therefore plugins and custom devices. It only supports built-in device types.

Indigo Touch doesn't use the REST API.