/list call fails systematically after /auth since V2

Hi,

We have been working with Nuki for some time now through the HTTP API integration. We have never had any issues with the authentication before.
Since two weeks ago approximately, we are facing consistant failure during pairing with 401 Unauthorized error message. We haven’t changed the hashing method which used to work well before.

Conditions: Bridge fw 1.11.4 and Lock paired together. Using the API with the hashed secure method only, not raw token. The time in the bridge and in our system seems to be equal.

Steps:

  • discover bridge: OK
  • authentication: OK
  • /list call with hashed token: Fails all the time
  • retrying /list after a few seconds fails as well

Has there been an update recently that could have impacted that? Do you see any reason why the bridge returns 401?

Here are the bridge logs during the process described above.
{
“timestamp”: “2019-06-26T15:24:24+00:00”,
“type”: “WLAN-SocketDisconnected”,
“connection”: 0
},
{
“timestamp”: “2019-06-26T15:24:24+00:00”,
“type”: “Button-Pressed”,
“time”: 2000
},
{
“timestamp”: “2019-06-26T15:24:24+00:00”,
“type”: “HTTP-AuthSession”,
“status”: “done”,
“success”: true
},
{
“timestamp”: “2019-06-26T15:24:19+00:00”,
“type”: “HTTP-AuthSession”,
“status”: “started”
},

Thanks,
Alex

Hashed token was only introduced with Bridge FW 1.12.0.
You write that you are at 1.11.4 at the moment (which is quite outdated), is this correct?

The bridge should update automatically if it can reach our server to check for new versions.

Yes that’s right, sorry I got confused between my two bridges.
So it seems the issue with the new bridge is a timing issue. The hash mechanism seems to be slowing down the bridge which cannot receive the next command as quickly as before. Adding a delay fixes it.