Unable to authenticate with token for API requests with NxMeta cloud
Answered
I went throught this example https://github.com/networkoptix/nx_open_integrations/blob/master/python/examples/authentication/cloud_bearer.py and it works. Only instead of
LOCAL_URL = 'https://localhost:7001
I used
LOCAL_URL = 'https://{system_id}.relay.vmsproxy.com'
But when I try to perform request
devices_info = request_api(LOCAL_URL, f'/rest/v1/devices', 'GET',
headers=primary_token_header, verify=False)
It returns
Request error 401
<HTML><HEAD><TITLE>Unauthorized</TITLE></HEAD><BODY><H1>401 Unauthorized -- Forbidden</H1></BODY>
/rest/v1/devices
request works from API documentation, though. Im not sure what could be wrong.
-
Hello,
Most probably, your request is redirected to the nearest relay. You should retain authorization headers when a request is redirected.
Here is a thread discussing it in detail.
https://support.networkoptix.com/hc/en-us/community/posts/6909663034391/comments/9781787859095
You could pass the additional parameter
allow_redirects=True
to the request_api function.
-
I tried using redirects, doesnt help. And I also tried using last redirect link that is returned in reply:
Access-Control-Allow-Origin: *
Content-Length: 70
Content-Type: application/json
Date: Thu, 20 Apr 2023 03:00:51 GMT
HTTP/1.1 307 Temporary Redirect: present
HTTP/1.1 401 Unauthorized: present
Location: https://{server_id.}dp-ny-3.vmsproxy.com/rest/v1/devices
Server: Nx Witness/4.3.0.33570 (Network Optix) Apache/2.4.16 (Unix)
Strict-Transport-Security: max-age=31536000
WWW-Authenticate: Digest realm="VMS", nonce="svyZDY....=hzxieq", algorithm=MD5
X-Auth-Result: Auth_Forbidden
X-server-guid: {dcebc02b-14f.....}But it returns same reply, Auth_forbidden
-
By the headers you've sent, I conclude that you're using digest/basic authorization scheme. Make sure the user account has this scheme enabled.
I configured Postman to retain auth header during redirects by enabling the setting
Follow Authorization header
Retain authorization header when a redirect happens to a different hostname.
The first and the second requests return a "nonce" for further auth calculation.
The first request is just redirection to the relay-ams relay, as it's indicated on the screenshot.
The second request to the "relay-ams" relay returns
X-Auth-Result: Auth_Forbidden
and, in the WWW-Authenticate header, the nonce which should be used in further auth calculation.
The third request, already supplied with a correct Authorization header, is just a redirect to the relay-ams relay, again.
The fourth request is the one to the relay-ams relay and retains Authorization header (This is what Follow Authorization header setting does. This is also what you should do in your application). As you can see, the request is successful and returns a correct payload with camera information. -
If the software you use does not handle redirections correctly, you could follow this pipeline for developing your own redirection handler.
- Resolve the actual currently assigned relay for this system by sending a GET request to https://{systemId}.relay.vmsproxy.com/someApi. E.g. https://51eab27a-35a2-4b3d-a150-d69a627138f5.relay.vmsproxy.com:443/someApi
- The relay might respond with 307 Temporary Redirect(mainstream option) or with 200 OK(deprecated and will be soon removed)
- In case of 307 response code, the actual location will be delivered in the 'Location' response header. E.g. 'Location': 'https://51eab27a-35a2-4b3d-a150-d69a627138f5.relay-ny2.vmsproxy.com:443/someApi'
- Use the new location to send the api request with the authorization header containing the access token
- In case of 200, the response body will contain the requested info right away -
Thanks for sharing the solution Andrey Terentyev. I can get the actual location and make a subsequent request to retrieve the response.
Please sign in to leave a comment.
Comments
6 comments