Tasker HTTP Post: Invalid Authentication

Hi, I’m trying to set up a Tasker HTTP post and am having trouble with authentication.

I have my settings as:

  • server:port = https://myurl.duckdns.org
  • path = /api/services/light/turn_on?api_password=MYPASSWORD
  • data/file = {“entity_id”:“light.mylight”}
  • content type = application/json

When I run this task I get an error popping up on my HA front end showing “Login Attempt Failed: Login Attempt or Request with invalid authentication”…

I’ve double checked the password and am stuck for what to do next. I’m running HASSIO (0.69.1) on an RPi3 with the DuckDNS plugin…

Can someone help? Thanks! :slight_smile:

This probably needs to be:
server:port = https://myurl.duckdns.org:8123

Have you tried using a POST generator (like Postman for Chrome) to debug? I do this with Tasker and have it structured the same as you do. I don’t believe you want to specify port 8123.

Have you confirmed that you can POST from outside your network?

Curious why you would say this. The API clearly states that it is available on that port (at least by default.)

https://developers.home-assistant.io/docs/en/external_api_rest.html
How could Tasker know the port number if you don’t tell it? (I would guess it probably defaults to port 443, which is the default port for HTTPS.) FWIW, I’ve done this with IFTTT, and I have definitely specified port 8123 along with the IP address.

I agree, though, that using something like Postman or curl can help work out the correct request. Then it’s just a matter of translating that into the tool of interest (such as Tasker.)

HTTPS implies 443. But yeah - I guess it depends on how you’ve configured port forwarding on your router. If you mapped 8123 instead of 443, you’d need that.

1 Like

Thank you both! When I specify 8123 it actually throws an error in Tasker and doesn’t work so I got to leaving it off more by trial and error than anything… I have the same for some of my other http services that I use…

I haven’t ever heard of Postman @ih8gates but will give it a go! Odd that my settings are the same as yours but not working… All my tests were done within my network, will give it a go outside and see what happens…
EDIT: I get the same issue from outside my network :frowning:

@ih8gates makes a good point. How is your router set up? Specifically does it forward an external port to your HA platform’s port 8123? If not, that’s your problem. If it does, what external port is forwarded to 8123? (I’m assuming HA’s HTTP component is configured to use the default port of 8123. If you’ve changed that, then you’ll need to take that into account as well.)

You can use http://canyouseeme.org/ to check if the port you think you should be using from the outside actually has something listening on it. I believe you have to run this from a computer on your LAN.

Hi @pnbruckner - yeah I have it set up to forward 443 to 8123 so I think that’s okay?

Could it be a similar issue to those faced in this thread around the certificates? IFTTT troubleshooting... Maybe duckDNS and let's encrypt issues?

Well, I guess that depends on how you have things set up. FWIW, I’m also using DuckDNS and LetsEncrypt, and I can call the HA HTTP API from outside. But I’m forwarding 8123 to 8123.

How do you have http: base_url configured? I believe that is supposed to be your external IP name and port. So, in your case, I believe it should be (with the actual name): myurl.duckdns.org:443. But that’s probably also necessary for the browser interface, so I’m guessing that’s not a problem. (Just something to check.)

I set up the LetsEncrypt stuff a while ago (using dehydrated), and I found that the fullchain.pem and privkey.pem that it created were symbolic links, and I’m pretty sure HA had a problem with that. I ended up changing the dehydrated bash script to create hard links instead, and then it worked. (I.e., for those to links I changed the ln -sf ... commands to ln -f xxx.) But it was a while ago and it could have been I did something else wrong that I fixed and never went back and changed these back to symbolic links. Anyway, just a thought.

Sorry if this isn’t helping.

EDIT: Never mind about my symbolic vs hard link comments above. I went back and changed the hard links (privkey.pem and fullchain.pem) back to symbolic links and everything still works. So apparently it was something else that caused things not to work when I was first setting this up that I obviously fixed.

Have you made any progress? I’m guessing that since the error was invalid authentication it probably wasn’t a certificate issue. Don’t know for sure, but I would think if Tasker didn’t like your system’s certificate it wouldn’t get that far.

I just tried turning a light on via the API using the curl command on Linux and it works fine for me. If you have that you might want to try it. Probably easier than getting postman set up (although I use that, too.) It would look like this:

curl -X POST -H "Content-Type: application/json" -d '{"entity_id":"light.mylight"}' "https://myurl.duckdns.org/api/services/light/turn_on?api_password=MYPASSWORD"

Whether that works or not would hopefully give you some clues. BTW, you should be able to do that either on your LAN or outside it. If you do it from the LAN, it should effectively go “out” through your router and back in, and work just the same as if you were outside your LAN.

Thanks @pnbruckner !

I’ve just figured it out!! Turns out it was because my api password had special characters in it, so I changed my password to be only alphanumeric and hey presto! Thanks so much for your help :smiley:

So was it a Tasker problem because of the character in the password? May I know which character, maybe ! ?
I am having similar issue

I can’t remember exactly which characters but I removed all special characters (so &?#% etc) and just left letters and numbers then it worked