Error 401 CALL API - Sequrinet - NxPlugin
Answered
Hello,
When I want to use the NxPlugin (SEQURINET) =>
1.Cameras Update (Make a CALL API to the Nx server for /getCameras)
The response from Nx is:
2022-05-04 11:29:31.181 a58 DEBUG HTTP: Received request from 172.16.10.18:38282:
GET /ec2/getCamerasEx/ HTTP/1.1
Host: 172.16.10.201:7001
User-Agent: python-requests/2.19.1
Accept-Encoding: gzip, deflate
Accept: /
Connection: keep-alive
~~~~~~~~~~~~~~~~~~~
2022-05-04 11:29:31.181 a58 DEBUG HTTP: Sending response to 172.16.10.18:38282:
HTTP/1.1 401 Unauthorized
Date: Wed, 04 May 2022 11:29:31 +0200
Connection: Keep-Alive
Keep-Alive: timeout=5
Content-Type: text/html; charset=utf-8
X-Auth-Result: Auth_WrongDigest
X-server-guid:
{12628405-7ae5-47bf-6be7-47e12936d6b9}
Content-Length: 84
WWW-Authenticate: Digest realm="VMS", nonce="bplYS+IWijAKQY0sfZeft28RmfgQvQ=hzptcu", algorithm=MD5
Access-Control-Allow-Origin: *
-------------------
2022-05-04 11:29:31.216 a58 DEBUG HTTP: Received request from 172.16.10.18:38282:
GET /ec2/getCamerasEx/ HTTP/1.1
Host: 172.16.10.201:7001
User-Agent: python-requests/2.19.1
Accept-Encoding: gzip, deflate
Accept: /
Connection: keep-alive
Authorization: Digest username="admin", realm="VMS", nonce="bplYS+IWijAKQY0sfZeft28RmfgQvQ=hzptcu", uri="/ec2/getCamerasEx/", response="b6ebaf970ebe980a67bd6337991f968b", algorithm="MD5"
~~~~~~~~~~~~~~~~~~~
2022-05-04 11:29:31.226 a58 DEBUG HTTP: Sending response to 172.16.10.18:38282:
HTTP/1.1 200 OK
Date: Wed, 04 May 2022 11:29:31 +0200
Pragma: no-cache
Server: Nx Witness/4.2.0.34633 (Network Optix) Apache/2.4.16 (MSWin)
Connection: Keep-Alive
Keep-Alive: timeout=5
Content-Type: application/json
Cache-Control: post-check=0, pre-check=0
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Content-Length: 10358
Content-Encoding: gzip
Access-Control-Allow-Origin: *
I have this error on several clients,
I tried NxServer version 4.2.0.34633 & 4.2.0.32840 but I get the same thing.
I opened a ticket at SEQURINET, but they don't have the problem when they try to reproduce it.
I have the same configuration with other customers and it works.
I don't understand where the problem comes from
I can give you access to the server for testing if you wish.
Regards
-
Hi Jordan IUNCKER,
Besides the HTTP/1.1 401, do you experience actually any issue with receiving the event in Nx from AIBox?
If so what is the issue you experiance?What could be is that they use Cookie-based authentication, and in that case the HTTP/1.1 401 is expected behavior?
This can also be seen in the HTTP log:-------------------
2022-05-05 11:15:02.401 880 DEBUG HTTP: Received request from 172.16.10.18:39770:
GET /ec2/getCamerasEx/ HTTP/1.1
Host: 172.16.10.201:7001
User-Agent: python-requests/2.19.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
~~~~~~~~~~~~~~~~~~~
2022-05-05 11:15:02.402 880 DEBUG HTTP: Sending response to 172.16.10.18:39770:
HTTP/1.1 401 Unauthorized
Date: Thu, 05 May 2022 11:15:02 +0200
Connection: Keep-Alive
Keep-Alive: timeout=5
Content-Type: text/html; charset=utf-8
X-Auth-Result: Auth_WrongDigest
X-server-guid: {12628405-7ae5-47bf-6be7-47e12936d6b9}
Content-Length: 84
WWW-Authenticate: Digest realm="VMS", nonce="bplYS+IWijAKQY0sfZeft28RmfgQvQ=hzzoou", algorithm=MD5
Access-Control-Allow-Origin: *
-------------------
2022-05-05 11:15:02.459 880 DEBUG HTTP: Received request from 172.16.10.18:39770:
GET /ec2/getCamerasEx/ HTTP/1.1
Host: 172.16.10.201:7001
User-Agent: python-requests/2.19.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Authorization: Digest username="admin", realm="VMS", nonce="bplYS+IWijAKQY0sfZeft28RmfgQvQ=hzzoou", uri="/ec2/getCamerasEx/", response="b57db3117b70dfa605f9ddf0d5abedad", algorithm="MD5"
~~~~~~~~~~~~~~~~~~~
2022-05-05 11:15:02.469 880 DEBUG HTTP: Sending response to 172.16.10.18:39770:
HTTP/1.1 200 OK
Date: Thu, 05 May 2022 11:15:02 +0200
Pragma: no-cache
Server: Nx Witness/4.2.0.34633 (Network Optix) Apache/2.4.16 (MSWin)
Connection: Keep-Alive
Keep-Alive: timeout=5
Content-Type: application/json
Cache-Control: post-check=0, pre-check=0
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Content-Length: 10336
Content-Encoding: gzip
Access-Control-Allow-Origin: *
-------------------First, they receive the HTTP/1.1 401, and for the second request they receive the HTTP/1.1 200 OK.
This is expected behavior.0 -
Hi Norman
I open a ticket with the NxSupport,
Joe & John & Jimmy check righ now the problem, I think the ITX team come back to you to search what the real problem
I tried the API
https://<externalServerIp>:7001/ec2/getCamerasEx
And it works correctly internally & externally.
So it's a communication problem between SEQURINET and NxWitness through the NxPlugin0 -
Please answer this question first:
what is the issue you experience?
0 -
Hi Norman
The problem is as follows: When I connect to the AIBOX module, I want to use NxPlugin to get camera information to set the AI to camera mapping.
0 -
Hi Jordan IUNCKER,
That is something to be resolved by AIBox.
First they receive the HTTP/1.1 401, but in the second attempt, they receive the HTTP/1.1 200 OK response.
This is because of the method they use to authenticate. It's not wrong, but probably needs an extra step.
In case AIBox needs assistance with that, they know how to reach our developer support.0 -
Hi Norman
I open a ticket with AIBox Team (Sequrinet)
John answer this about the issues :I checked your side Nx server configuration, But can not found any differences with our server.
This issue needs to be reviewed by the Nx development team.
About why it responds with 401 unauthorazation to a camera logged in with a normal id/password.0 -
Hi Jordan IUNCKER,
Nx responds with an HTTP/1.1 401 Unauthorized reply to the normal password, since a DIGEST password is mandatory. Nx can't process hardcoded credentials for security reasons and hashing the credentials is required.
See our API documentation about this and navigate to Cookie-Based authentication (1):
We reviewed this already, they first get the HTTP/1.1 401 Unauthorized (2), and then when the credentials are hashed correctly, they get the HTTP/1.1 200 OK reply (3). See also the documentation as shown above.
But their system most likely doesn't follow this method as documented.
The reason they can't reproduce it, is likely due to a recent login and the password hash in the session cookies.In case AIBox needs assistance with that, they know how to reach our developer support.
0
Please sign in to leave a comment.
Comments
7 comments