Assistance with "Make web request" action

#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:

#50

I’d recommend using using IFTTT maker but then it will need to be on WAN and you already have that working.

I’m surprised digest works on WC over WAN… my understanding was that it shouldn’t work for LAN or WAN.

#51

Out of interest, what commands are you trying to send to your camera?

Is it something Blue Iris can be the middle man for?

#52

@Robin sorry for not responding sooner. Apparently new users on this forum are limited to the number of replies that can be made each day. So I was forced to wait.

So far I’m sending commands to the camera to enable/disable video recording, enable/disable motion detection, start/stop a tour, and go to a preset. I’m also querying the alarm status so I can determine if the camera has detected motion.

Yes, even before starting this recent effort of integrating the camera with SmartThings, when I first got the camera I was considering Blue Iris. However, for a couple of reasons I haven’t gone that route yet. First, I didn’t want to pay for a program I wasn’t sure I needed. (And, yes, I know they have a free version, but… There’s also other options like tinyCam, Amcrest’s apps & cloud, etc. so I needed the dust to settle a little before deciding.) Second, I’ve been an embedded software developer for over forty years and I haven’t done anything like this, so I’m also using this as a learning exercise. :blush:.

@ady624 @ipaterson I don’t know if you’ve had time to follow this discussion, but I was wondering if you know why when using an internal (i.e., 192.168.x.x) address in WC’s web request action it doesn’t support digest authentication (which is required by the target of this request), but when using an external address (and without changing anything else about the request) it does properly negotiate with the target and use digest authentication? Or more importantly, can using an internal address be fixed/enhanced to properly negotiate and use digest authentication? If it helps, I can provide any logs, details or wireshark captures you might want.

#53

Here is an example of negotiating Digest authentication with LAN requests using HubAction. It is possible if anyone wants to take on the challenge. The example is 3 years old now and the author indicated that at the time it was not possible to run more than one local request per minute, so there may still be some limitations.

#54

This is not something I feel I could take on. I’m just too inexperienced in writing code for ST.

Should I add a new topic for this under Meta / Feature Suggestions?

BTW, I tend to agree with the comments in the ST forum topic I referenced above, and that is that the ST framework should add support for digest authentication. I.e., take the burden off the DTH or SmartApp. But that’s just my 2 cents.

#55

Yep! Web requests and array variables are two areas that I hope to spend some time in once I start working on features, there should be a tag you can apply to the feature suggestion for web requests to make it easy to find later.

Support for digest authentication with web requests using internal addresses
#56

I added a ‘todo’ tag :smile:

#57

I created the feature request:

FWIW, I didn’t see a web request or todo tag. Can I just input a new tag, or can I only select from the options that come up?

#58

Anyone can create a tag… though I’ve made the todo tag ‘staff only’ to avoid any abuse.