loadChatRoomUnreadMessages causes failure to login

[taoeffect]

Problem

While testing the app with grunt dev --tunnel I got this error on my phone:

Note that I was already logged in!

This is caused by this code in actions/identity.js:

      // NOTE: update chatRoomUnreadMessages to the latest one we do this here
      //       just after the identity contract is synced because
      //       while syncing the chatroom contract it could be necessary to update chatRoomUnreadMessages
      await sbp('gi.actions/identity/loadChatRoomUnreadMessages')

This code failed because fetchChatRoomUnreadMessages => chelonia/kv/get returned 401 Unauthorized.

I think the reason I got this error was because of this on the server-side:

[11:45:59.155] WARN (88570): Shelter authorization failed
    err: {
      "type": "Error",
      "message": "Invalid signature time range",
      "stack":
          Error: Invalid signature time range
              at verifyShelterAuthorizationHeader (shared/domains/chelonia/utils.js:760:11)
              at Object.authenticate (backend/auth.js:43:72)
              at exports.Manager.execute (node_modules/@hapi/hapi/lib/toolkit.js:51:36)
              at module.exports.internals.Auth._authenticate (node_modules/@hapi/hapi/lib/auth.js:258:58)
              at authenticate (node_modules/@hapi/hapi/lib/auth.js:234:21)
              at Request._lifecycle (node_modules/@hapi/hapi/lib/request.js:372:68)
              at processTicksAndRejections (node:internal/process/task_queues:95:5)
              at Request._execute (node_modules/@hapi/hapi/lib/request.js:280:9)
    }

Solution

There are two questions here:

1. Why did this error happen in the first place and how can we prevent it?
2. If the error happens during login, should we be logged out immediately (as happens now) or should there be an exception handler around this line so that it's logged bug "ignored" if it fails?

[corrideat]

1. It likely happened for the reason the error says, i.e., a time mismatch. The underlying cause for this could be, non-exclusively:
   1. the server and the phone disagreeing about time (possible, but unlikely unless there's evidence to the contrary)
   2. the tunnel adding some time delay, in this case over 2s.
      As far as prevention goes, we could increase the time window (e.g., to 5 s (*)). The point of doing this check, as the accounting document says, is to prevent nonce reuse and to prevent certain replay attacks.
2. This likely shouldn't be a fatal error logging you out.

(*) Or to something even larger (e.g., 60s or even an entire day). The reason the window is so short right now is that the server is supposed to reject used nonces (not implemented). In this case, a short window helps because it's fewer values to remember. In any case, I think this should be a configurable setting with a sane default value (instead of a hardcoded value) as it pertains the server and administrators can weigh the trade-offs and set smaller or larger windows.

[taoeffect]

Since you increased the time let's consider this fixed.