Assistance with "Make web request" action

#30

will try and report back later when home.

#31

One more thing you may want to look into:

Make sure your password doesn’t have any symbols. I just changed my password to make it more secure and it kept failing. I swapped out the symbols and now it works just fine.

#32

that was it. password was too secure. :slight_smile:

will try later by encoding the symbols properly in the URL.

thanks much!

Security Camera Tile
#33

How do you deal with the returned value? Is it stored in a variable?

#34

$response

Hit the test button on this example an it will log your IP

image
image.png1178×342 17.8 KB

URL:
http://httpbin.org/ip

#35

I’ve been successful controlling my Amcrest camera and getting data from it using the same techniques described above. I.e., set up port forwarding in my router and use an external address in my web request along with user:pw & port number in an (unencrypted) HTTP request.

However, I’d rather 1) use HTTPS, or 2) preferably, keep the communications on the LAN.

I couldn’t get the first option (HTTPS) to work because the camera is using a self-signed certificate and ST complains that it can’t be authenticated. Any ideas how to resolve this issue?

But, as I said, I’d prefer to keep the communications between ST/webCoRE and the camera on my local LAN. If I change the web request to use the LAN IP address for the camera instead of the external address, and drop the port number (since the default port of 80 is correct), it doesn’t work. By logging $httpStatusCode I see the result is 408, which is a timeout.

So, with everything else the same, why does a local address not work if an external address does?

Details:

External web request:

http://:@<external_address>:<external_port>/cgi-bin/…

Internal web request:

http://:@<internal_address>/cgi-bin/…

For the first, the log shows:

Sending external web request to: <external_address>:<external_port>/cgi-bin/…

And $httpStatusCode is 200.

For the second, the log shows:

Sending internal web request to: :@<internal_address>/cgi-bin/…

And $httpStatusCode is 408.

Of course, both forms work from Chrome or Postman. What is webCoRE doing differently between external and internal addresses that would cause the internal address form of the web request to not work?

#36

Sorry, the username & password part of the web requests I typed above didn’t show up. They both start with “http://user:pw@”. (I should have looked more closely at the preview pane before clicking Reply!)

#37

Adding picture of script and log:

image
image.png986×1117 77.1 KB

#38

You’re using the wrong type of authentication… try:

IP/request…&user={USERNAME}&pw={PASSWORD}

The password works in two ways, either by means of Basic Auth http://user:pass@… (which you are trying) or by means of query string http://…&user=…&pw=…

The first way with user:pass@ does not work - it gets blocked. The latter one does.

#39

Thanks!

Yes, I’ve seen this suggestion while browsing related topics, but I tried it and it does not work, and I’ve seen others reply that it doesn’t work for them either. To be specific, I’m using an Amcrest IP2M-841 w/ software version 2.520.AC00.18.R, Build Date: 2017-06-29. It appears that it does not accept user= and pw= in the query string.

I believe this is an issue of basic vs digest authentication. I don’t claim to know much about this, but I’ve seen others comment on this, especially that newer versions of Amcrest IP camera software disabled basic authentication and digest must be used. I’ve also seen in Chrome and Postman that they’re using digest authentication when talking to this camera.

So, the question becomes, why is webCoRE/ST able to send the request (w/ http://user:pass@) successfully to this camera if I use an external address/port (where it MUST be using digest authentication), but not successful (i.e., causing a 408 timeout) if I use an internal IP address?

I’ve browsed the webCoRE code a little, and clearly there is different code for sending external and internal web requests. Is there something different in these two paths that can explain this behavior? (Who is responsible for this part of webCoRE? Can someone check with that person?)

Also, I’ve seen the suggestion to disable login in the camera for LAN accesses, which has apparently worked for other people using other IP cameras. However, this Amcrest camera with this version of software only provides a check box for “anonymous login”, and although that does allow access without a login, in that case it limits that access to only previewing the video. Or to put that another way, it does not allow the types of accesses I’m trying to do (e.g., PTZ, getting alarm state, etc.) So, that option won’t work for me.

#40

As a confirmation that &user=user&pw=pass does not work (for me), I altered the web request that was working (the one that used http://user:pass@ with an external address & port) to remove user:pass@ and add &user=user&pw=pass, and got this error in the log:

Error executing external web request: groovyx.net.http.HttpResponseException: Unauthorized

#41

Could this help explain it:

Seems like httpGet must know how to use digest authentication, but HubAction (or the way it’s being used), does not???

#42

Here is where I read a lot about basic vs digest authentication in relation to Amcrest IP cameras:

This thread is about a DTH for the Amcrest cameras, and the author (I believe) has concluded that since Amcrest disabled support for basic authentication, and since the ST SmartApp framework doesn’t support digest authentication, there’s no way for this to work. However,…

However, as I and others have commented, using an external IP address w/ webCoRE works, but as I’ve found, using an internal IP address doesn’t. So, digest authentication can work on ST. My guess, again, is the method required to send requests locally (HubAction?) either can’t do it, or the way webCoRE is using it causes it to fail.

Who is the most knowledgeable about how web requests work in webCoRE?

#43

@ady624 @ipaterson

#44

Have you tried using the authentication header method?

#45

So I did see that suggestion, but I stopped as soon as I saw the Authorization header was not showing a “Basic blahblahblah” string, but was instead a rather lengthy digest authentication header. From the very little I read about basic vs digest, I concluded this couldn’t work because the digest authentication header is based on more than just the (static) username/password, but included part of the request itself. (I think this is what makes it more secure???) But, if you think I could copy a digest header string into the webCoRE request’s authentication header field, I’ll give it a shot.

#46

I have no idea… but it must be worth a try.

#47

Btw… The Authorisation header is just base64 encoding of username:password (you can generate the value here)

#48

To close the loop on trying the authentication header field, it did not seem to work. I removed username:password@ from the URL field, and copied the authentication header from Chrome to the Authorization header field of the webCoRE request.

#49

I think this explains why it can’t work: