HTTPd Plugin (useful for IFTTT Maker integration)

[FlyingDiver]

Apologies if I missed this, but does this work with digest authentication?

No. Indigo's built in web server does digest authentication. I only wrote this plugin for use with services that don't do digest authentication, like IFTTT.

[mundmc]

Apologies if I missed this, but does this work with digest authentication?

No. Indigo's built in web server does digest authentication. I only wrote this plugin for use with services that don't do digest authentication, like IFTTT.

Roger that. I still plan to use. I suppose I'll track down a PHP script to run as a server, add digest, and push to Indigo.


Sent from my iPhone using Tapatalk

[FlyingDiver]

Roger that. I still plan to use. I suppose I'll track down a PHP script to run as a server, add digest, and push to Indigo.

If you have digest authentication available on the request initiator, why not use an IWS plugin? See http://forums.indigodomo.com/viewtopic. ... 13&t=17208 for an example.

[Gusten]

Hi when using this to make IFTTT update a variable it works but there is always a blank before the variable so indigo don't interper numbers as numbers. Is there anyway to get the plugin to not put the blank infront of the data?

Thanx

/Martin


Skickat från min iPhone med Tapatalk

[FlyingDiver]

Hi when using this to make IFTTT update a variable it works but there is always a blank before the variable so indigo don't interper numbers as numbers. Is there anyway to get the plugin to not put the blank infront of the data?

The plugin is not adding the blank. It's coming from IFTTT that way.

[dhughes]

Hello!

I am trying to use the httpd plugin to respond to a Flic button. The Flic button handler has a URL request option (Put, Get, etc.).

My issue is that the Flic action doesn't support http://username:[email protected].

It does support basic authentication using headers, but I can't seem to get it to work. The plugin still returns "Basic Authentication Required"

I have tried both these headers and get the same result:

Authentication: Basic username:password
Authentication: Basic username:password with "username:password" encoded in Base 64

Does the plugin support authentication headers and I am doing something wrong or are they currently not supported by the plugin?

Thanks,
Dan

[FlyingDiver]

The header is "Authorization" not "Authentication". So you should be sending:

Authorization: Basic username:password (with "username:password" encoded in Base 64)

[dhughes]

Some days I feel significantly dumber than others. Today is one of those days.

Made the fix and... fantastic! Trigger in Indigo is immediate upon pressing the Flic.

Thanks for contributing the plug in and thanks for helping me pull my you-know-what out of my you-know-where.

Regards,
Dan

[FlyingDiver]

Been there, done that. You're welcome.

[dhughes]

I'm baaaaack... I am getting this when the plugin tries to start.

Traceback (most recent call last):
File "plugin.py", line 152, in runConcurrentThread
File "/Library/Application Support/Perceptive Automation/Indigo 7/Plugins/HTTPd.indigoPlugin/Contents/Server Plugin/ghpu.py", line 88, in checkForUpdate
File "/Library/Application Support/Perceptive Automation/Indigo 7/Plugins/HTTPd.indigoPlugin/Contents/Server Plugin/ghpu.py", line 175, in _prepareForUpdate
File "/Library/Application Support/Perceptive Automation/Indigo 7/Plugins/HTTPd.indigoPlugin/Contents/Server Plugin/ghpu.py", line 97, in getUpdate
File "/Library/Application Support/Perceptive Automation/Indigo 7/Plugins/HTTPd.indigoPlugin/Contents/Server Plugin/ghpu.py", line 117, in getLatestRelease
File "/Library/Application Support/Perceptive Automation/Indigo 7/Plugins/HTTPd.indigoPlugin/Contents/Server Plugin/ghpu.py", line 145, in _GET
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 973, in request
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1007, in _send_request
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 969, in endheaders
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 829, in _send_output
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 791, in send
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1176, in connect
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 387, in wrap_socket
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 143, in __init__
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 305, in do_handshake
SSLError: [Errno 1] _ssl.c:504: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

HTTPd Error plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

[FlyingDiver]

See http://forums.indigodomo.com/viewtopic. ... 77&t=20234

[dhughes]

Perfect! Thank you.

I appreciate your contributions! You are a gentleman and a scholar.

[cjp767]

I’m giving this plugin a try, and making great progress, but I am failing authorization as referenced in the Indigo log. My port forwarding seems fine, since I’m getting failed authorization messages in the log.

I read above that the username and password should be in base 64, and there are plenty of converters online, but I’m still confused.

Is it true that they username and password must match only between the plugin setup and the Ifttt message? And are they both base 64? And verify that this is neither my Indigo password and not my IFTTT password? It’s a username and password just between the ifttt message and the plugin, right?

How about this— give me an example of what I can put in userid and password on each side. I put QUJD both userid and password in ifttt and in the plugin setup. Help me along, I’m close!

Code: Select all

http://QUJD:[email protected]:5555/setvar?var1test=yay

(I broke that into 2 lines to be sure you could see all of it)

[FlyingDiver]

Yes, the username and password you pick here are JUST to authenticate to this plugin. Basically, the info you put in the IFTTT URL string needs to match what the plugin is configured for.

Go back and look at the very first post of the thread. You put exactly the same text in the URL string as you do in the plugin prefs. You don't do any kind of base 64 conversion. IFTTT takes the username/password pair specified in the URL string on their end, encodes the pair in Base-64, and sends it in an authentication header as part of the HTTP GET. The plugin then converts those back to plain text and matches them against the configuration data.

If there's errors in the log, please post them here.

Your URL string looks fine. When posting, if you're worried about the lines getting truncated, use CODE tags.

You could use "username" for the username and "password" for the password and it should work fine. I'm actually using "guest" and "password".

The tricky part is the port to use. If you're using something that your router is blocking or your Mac is already using it won't work. I'm using 5555.

[cjp767]

I don’t officially know if port 5555 is being used, but the port forwarding seems to work since a debug message appears in the log when I trigger the THAT. I have a widget button on my home screen to trigger.

I changed the username and password to guest and password. (Although cryptic, they matched in my previous tries too, though)

AuthHandler: Get from 52.23.154.5:40962 for /setvar?var1test=yay
AuthHandler: Request with invalid authorization header

Here is my Code line in ifttt. (xxxxxx hides my dyndns address)

Code: Select all

  http://guest:[email protected]:5555/setvar?var1test=yay 

Method is GET
Content Type is text/plain
Body is just blank, no characters or spaces added.

In Indigo, the plugin has added a section in the variable list that says HTTPd, but says no items found.

Thank you for any guidance. I am probably missing something obvious... that’s pretty normal.