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
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???
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?
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.
Btw… The Authorisation header is just base64 encoding of username:password (you can generate the value here)
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.
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.
Out of interest, what commands are you trying to send to your camera?
Is it something Blue Iris can be the middle man for?
@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. 
.
@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.
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.
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.
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.
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?
@Robin… did this ever get figured out? I’m trying to have WebCore send an http or https command to my Blue Iris server. I want to trigger a camera to record when a Smartthings motion sensor “sees” motion. I’ve tried a lot of things but nothing is working. Thanks!
Here are example commands that work from a web browser on my LAN.
https://192.168.1.16:8344/admin?camera=Driveway_Clone&trigger&user=username&pw=password
http://192.168.1.16:8347/admin?camera=Driveway_Clone&trigger&user=username&pw=password
