Troubleshooting "unauthorized access" in shortcut

As far as I can tell, I've followed the instructions at https://wiki.indigodomo.com/doku.php?id ... :shortcuts

I've tried my reflector name in the URL, also "indigo.local" and the IP address, properly using https or http in each case.

When I use the reflector, I get "unauthorized access" as a response inside Shortcuts and:

Code: Select all

   Web Server Warning              access denied for request /v2/api/command/ from XXX.XXX.XXX.XXX


(redacted)

Perhaps a hint or a red herring, but using either local URL results in either unreachable, or weirdly, the shortcut running seemingly endlessly and no log messages.

I've tried a new API key, with no change. Update2: indigo.device.turnOn also gave Unauthorized Access.

I'm targeting a Device Group. Does that change anything? Also the docs don't point me to a list of what I could use besides "indigo.device.toggle" and I'm unsure where to look for the proper syntax for "indigo.device.on"'s proper syntax.

What's my next step for troubleshooting this?

Update: tried targeting a device ID, and no change. Update 2: indigo.device.turnOn also same result.

[jay (support)]

This is an authentication failure, not a command failure, so it never actually gets to the point of trying the command (or even validating it).

Go to the Indigo 2023.2->Advanced Web Server Settings... and click on the Clear Cache button. Also, enable debug logging, then try again. Post any relevant debug information if it doesn't work.

I've tried my reflector name in the URL, also "indigo.local" and the IP address, properly using https or http in each case.

This seems to indicate that you've got some network configuration issue. Try this:

Code: Select all

http://localhost:8176/

and enter your username and password. Then try your IP address followed by your Mac's bonjour name. Each of those should work. Let us know which work and which don't.

localhost:8176 works fine, as do IPADDRESS:8176 and redacted.local:8176

Enabled debugging after clearing the cache. Not entirely sure why the web server restarted below, but it did.

Code: Select all

Error (client)                  timeout waiting for plugin response from com.indigodomo.webserver for request UiClosed1
   Web Server                      ...restarting Indigo Web Server
   Reloading plugin "Web Server 2023.2.0" using API v3.3
   Stopping plugin "Web Server 2023.2.0" (pid 1433)
   Reflector                       shutdown reflector connection
   Stopped plugin "Web Server 2023.2.0"
   Starting plugin "Web Server 2023.2.0" (pid 37181)
   Web Server Debug                Debug logging enabled...
   Started plugin "Web Server 2023.2.0"
   Web Server                      starting internal Web server on http://localhost:8176
   Web Server                      Indigo Touch client connected from 192.168.0.220
   Web Server                      Indigo Touch client connected from 192.168.0.204
   Web Server Debug                starting reflector connection
   Bonjour registered "Indigo - REDACTED"
   Web Server Debug                creating cache...
   Reflector                       starting reflector connection to https://REDACTED.indigodomo.net
   Web Server Warning              access denied for request /v2/api/command/ from REDACTED-External-IP

The unauthorized access problem continues. Probably not diagnostic, but I can ping the reflector URL no problem from the Indigo/shortcuts Mac.

Not entirely sure why the web server restarted below, but it did.

The webserver plugin restarts when you change the debug setting. This is normal.

[matt (support)]

Earlier you said:

Perhaps a hint or a red herring, but using either local URL results in either unreachable, or weirdly, the shortcut running seemingly endlessly and no log messages.

Can you clarify what happens when in the shortcut you use http://LAN_IP_ADDR/v2/api/command/... instead of https://REFLECTOR.indigodomo.net/v2/api/command/...?

Also, are you running the Indigo Web server behind a proxy server or anything? Anything else atypical about your ISP or networking setup?

http://IPADDRESS/v2/api/command/... = "could not connect to server"
https://IPADDRESS/v2/api/command/... = ''could not connect to server"

On a lark I tried http://REFLECTOR/v2/api/command/ and got

"Method not allowed"

There's no proxy server. My network setup:

WAN is a static IP from my ISP.

DNS provided by a piHole, fed to clients by my Unifi Dream Machine which is otherwise quite vanilla. Can't think of other configuration matters to describe that would be important. Indigo Mac has a static IP on ethernet and wifi, and the firewall is off.

Indigo Mac has a static IP on ethernet and wifi, and the firewall is off.

If you have Ethernet connected, disable Wifi. There are known issues with having both enabled.

Known issues with the web server?

I’ve had wifi and Ethernet on since day one of my first Indigo install. But I’ll give it a try.

Turned off WiFi. Still "Unauthorized access" result from the shortcut.

[jay (support)]

When connecting to anything other than the reflector, you have to include the correct port number (8176 is the default). I didn't see it in some of your above posts so just a reminder.

Also, be careful when you redact stuff. For instance, this line:

Code: Select all

Web Server Warning              access denied for request /v2/api/command/ from REDACTED-External-IP

is supposed to show a sanitized version of the token after the IP address is shown. If it doesn't, that's a different issue than if it does and you just removed it. If nothing shows up after the IP, it means that the auth header wasn't sent through to the server, so it never even got past that part of the process, and indicates something is wrong with the shortcut.

But, to test that authentication is actually working, put this script:

Code: Select all

import httpx

COMMAND_URL = "http://localhost:8176/v2/api/command"
HEADERS = {"Authorization": f"Bearer YOUR_API_KEY_GOES_HERE"}
DEVICE_ID = YOUR_DEVICE_ID_GOES_HERE

toggle_message = {
    "id": f"toggle_device_{DEVICE_ID}",
    "message": "indigo.device.toggle",
    "objectId": DEVICE_ID,
}
reply = httpx.post(url=COMMAND_URL, headers=HEADERS, json=toggle_message)
print(f"Reply received: {reply.status_code}")


into a file - call it apitest.py. Edit the script in the two places indicated to add your specific information (api key and device id).

Then, in a terminal, change to the directory where the script is and run the script like this:

Code: Select all

python3.11 apitest.py

You should get this output:

Code: Select all

Reply received: 200

And the device should toggle. Assuming that works, then change the COMMAND_URL to your reflector URL and try it again.

Let us know the results.

Code: Select all

Scripts % python3.11 apitest.py
Reply received: 401

I made doubly sure that I had the correct authorization key

Aside from clearing the cache on the Indigo Web Server again, is there a way to be sure the local Indigo is communicating back to the mothership about these Authorization Keys correctly?

Oh I'm also seeing this in the Indigo log, so the request seems to be reaching the server:

Code: Select all

 Web Server Warning              access denied for request /v2/api/command from 127.0.0.1


Code: Select all

 Web Server Warning              access denied for request /v2/api/command from 127.0.0.1


[jay (support)]

Hmmm. It's definitely not getting the auth header correctly. Something very strange is going on here.

Try creating a local secret to use rather than an API key. That will tell us if it could be an issue getting/validating API keys.

[jay (support)]

Also, email us this file (to support@indigodomo.com):

Code: Select all

/Library/Application Support/Perceptive Automation/Indigo 2023.2/Logs/indigoplugin.webserver/plugin.log

Be sure to add a reference to this forum topic.

So on that page for local secrets, this "The effect would be the same as unchecking the “Enable OAuth and API Key authentication” checkbox in the Start Local Server dialog, but with different logging when an authentication try fails. While valid, this configuration is not recommended; instead, users should use the OAuth setting when the server is first started (to avoid confusion)."

Gave me the clue I needed.

In the Start Local Server dialog box, I had "enable OAuth and API Key authentication" disabled. Probably something I turned off a year ago because I wasn't using it back then.

Apologies for the runaround. The shortcut is working now.