IWS/IOM?

I'm working on a plugin to interface the Automatic ODB-II API into Indigo. To use the API, I have to handle OAuth. I started writing an IWS plugin to handle the OAuth callback, but I'm having trouble storing the return tokens (as a variable? would I have access to prefs?).

From looking for documentation, I'm having trouble finding any documentation on how to interface with Indigo from within IWS. I mean, I guess I can read the source for cherrypy.server.indigoDb, but I don't see any actual documentation posted here. Also, I seem to recall seeing that IWS is more of a legacy technology for Indigo. Should I be using something else? Do the current Indigo 7 plugins have a way to provide web pages, too? Where is the documentation on that?

From IWS you have access to variables. Here's the code for my Twilio call-back IWS plugin. This sets a variable when Twilio does a call-back to notify me that a new SMS message is available.

Code: Select all

####################
import cherrypy
from indigopy.basereqhandler import BaseRequestHandler

####################
def PluginName():
   return u"Twilio Ping"

def PluginDescription():
   return u"This is the Twilio Ping Plugin."

def ShowOnControlPageList():
   return False      # if True, then above name/description is shown on the Control Page list index
   
####################
class TwilioRequestHandler(BaseRequestHandler):

   def __init__(self, logFunc, debugLogFunc):
      BaseRequestHandler.__init__(self, logFunc, debugLogFunc)

    def index(self, name=None):
        logmessage = "Twilio Ping usage: http://host:port/twilio/ping\n\n"
        self._Log(logmessage)
        cherrypy.response.headers['Content-Type'] = 'text/plain'
        return logmessage
    index.exposed = True

   def ping(self, **params):
      cherrypy.server.indigoDb.VariableSetValue(cherrypy.server.indigoConn, "twilio_ping", "true")
      return
   ping.exposed = True


See viewtopic.php?f=213&t=17208 for more info.

As an alternative to using IWS, you could include your own HTTP server in your plugin. Or use mine. viewtopic.php?f=216&t=17281

The biggest difference is that IWS requires that the initiator of the web request is able to use digest authentication. Rolling your own HTTP server does not.

If you get Automatic to work with Indigo, you will join the list of my heroes!

Hope it's compatible with my V1 Automatic.

FYI the indigo developers have stated before that it’s likely the IWS will be depreciated or at least changed significantly and they’ve recommended against people developing plugins for it.


Sent from my iPad using Tapatalk

[jay (support)]

You mean you have to act as an OAuth server (which seems very odd)? Client-side OAuth stuff can be done directly in the plugin.

You mean you have to act as an OAuth server (which seems very odd)? Client-side OAuth stuff can be done directly in the plugin.

Not a server, per-se, but you need an httpd server to get the call-back with the credentials. I expect it's because the Python library he's using was designed to be implemented in a web server.

I did try:

Code: Select all

         cherrypy.server.indigoDb.VariableAdd(cherrypy.server.indigoConn, "AutomaticODB-OAuthResponse", "test")


But end up with an error:

WebServer request to add variable "AutomaticODB-OAuthResponse" with value "test"
Error LowLevelBadParameterError

I am able to VariableSetValue(), but only if the variable already exists.

I'm having trouble reading the Variable(s), too (I was going to check and see if the Variable existed already, so I would know if I needed to VariableAdd() or VariableSetValue()).

As for the OAuth part, in order to be able to make use of Automatic's API, the user needs to log on to Automatic's web site and click a button to give permission to query the API for the user's information. Once the button is clicked, the user is redirected back to the "application" with a key that is to be stored and used for all API requests. I was going to set the redirect link to "localhost:8176", thinking the user would be doing this from the computer the Indigo server was on. This would then bring up my IWS page, which would capture the API key, which would be used by the regular plugin to interact with the API.

Does this direction make sense, or should I take a different approach?

I once wrote a Cocoa app that signed into Twitter using OAuth with a sign in web page in a window. The API requested a URL for the call back like the Automatic one does. But it wasn't actually used for my app. The authentication info was also returned in the page content, as I recall. It's been a long time since I wrote that code.

Is the Automatic API public? If it is, post a link so I can look at it and see if the same method would work from Python.

In any case, I don't think "localhost:8176" will work because it's the OAuth server that's going to be using that address.

https://developer.automatic.com/api-reference

I'm pretty sure "localhost:8176" will work - I have that part all working now. I'm just trying to store the response so I can use the data in it to make requests to the API. That, and determine if "IWS" is the appropriate approach for this, or if IWS is considered "legacy" and I should use something else.

Interesting. I'll have to take a look at your code to see what's actually going on.

As for your final question, if it was me I'd embed the http server in the plugin rather than rely on IWS. Just grab the code from my HTTPd plugin, it's not that complicated. Then you can save the info directly to your plugin rather than dance around with external variables.

[jay (support)]

As for your final question, if it was me I'd embed the http server in the plugin rather than rely on IWS. Just grab the code from my HTTPd plugin, it's not that complicated. Then you can save the info directly to your plugin rather than dance around with external variables.

Just note that if you take this approach you'll have to have a dynamic dns (or static ip) and you'll need to open a port on your router's firewall.

[jay (support)]

I've been using requests-oauthlib for doing client-side oauth in python - works well.

Just a quick look at those developer docs pretty much explains it: to use their RESTful API, you just need to use the tokens which are provided to your client app (in your case the plugin - you can use the library above) to get data from their system. In that instance, they don't need a URL because they're just responding to requests.

The Realtime Event API will require you to catch data pushed to a web server or a websocket. I'd imagine the push would be via a POST so you'd need to either write an IWS plugin or host your own http server. The websocket approach, however, may not need that as you might be able to open the websocket from your plugin and just leave it open to receive data - not sure about that.

I disagree with the static ip/dynamic DNS (for the OAuth part). I have a browser making a request to the OAuth "permission" page at Automatic's site, and once permission is given, their server side does a redirect to an URL of my choosing. I was planning on having that URL be "localhost", which would mean that you'd need to be on the box that your webserver is running on. At no time during that process is the Automatic's site making an actual request to me.

I'll give that library a look. Thanks!

I was going to start simple and just query the RESTful API every x minutes. They say that response is more accurate than the Realtime Events. I may try to incorporate the websocket approach. We'll see.

Jay - I guess I would need to use the Web Application flow, and just not care where the redirect goes to. Just let it be a 404 error somewhere, and then copy the redirect URL into the plugin config?

[jay (support)]

I don't think their API is designed to be consumed by another backend system because it relies solely on user interaction to authenticate (much like Alexa but in reverse - Alexa needs an OAuth server to authenticate, this system needs a client web-based UI flow to authenticate against their OAuth server). To do it their way you're going to have to write a IWS plugin or open your own HTTPS server and do port forwarding. Specifically, this:

When the user authorizes access, Automatic will make a GET request to the Redirect URL you have specified for you application. A temporary Authorization Code will be included in the code parameter.

So the GET request they send after your initial POST has the temporary code needed in the next POST you have to make in order to get the real access and refresh tokens.

There may be a way I'm just not seeing though, I haven't read their docs thoroughly.

UNLESS, that is, you require customers to get their own access token. From the docs:

During development, it may be easiest to obtain the access token for your own user account and hardcode it into your application. This would need to be removed and replaced with a proper workflow before pushing any application into production or having multiple users. Obtaining an access token for your own user account is simplified with tools in the Developer Apps Manager.

Note that "proper workflow" means the typical customer UI flow for OAuth authentication. So you could build your plugin such that it collects the access token from your plugin's config dialog. Then the user would need to log in to their system and get their own token. I believe there are a few other plugins that do something similar.