What browser are you using? I am using Chrome. I was unable to pass the uesrname and password in the URL to Blue Iris, but for some reason it worked just fine with Amcrest camera.
Also, which camera are you trying to run it on? Does it give you an error, an authentication popup asking for your Username and Password, or just nothing at all?
ok, that’s the same camera I’m using, so it should work. Let’s try a couple things:
If you are using your LAN ip (usually 192.168.x.x or 10.x.x.x) you will have to be connected to the same physical network as your camera (i.e.you can’t connect to that IP if you’re not also connected to the same router)
try doing an API call that doesn’t require any parameters:
http://user:pass@ip/cgi-bin/configManager.cgi?action=getConfig&name=General
where user/pass/ip are replaced with your info
try it in a different browser
I was using Chrome on windows, so maybe Chrome on a mac might work
try it without the :@ part
if you hit the correct link wihtout the user/pass it should give you an authentication pop up asking you to log in. If you don’t get the popup (which you are not) I am assuming there’s something wrong with the URI you are sending.
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.
that was it. password was too secure. 
will try later by encoding the symbols properly in the URL.
thanks much!
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?
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!)
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.
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.
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.
