Auth token time zone about mesh-client

[jamespic]

This should now be fixed in 1.3.0

[jamespic]

Cheers, this is a good spot.

I don't know for sure, but I've got a reasonable suspicion that the MESH team actually run their servers in UTC, so if there were a correct timezone for this, it would probably be UTC, although I note that this is underspecified in the API docs. All the production deployment I'm aware of that use this also run their servers in UTC.

In terms of what MESH actually does, I don't have access to the MESH server codebase myself either, so can't say for sure what this is used for internally (I've got contacts in the MESH team I can reach out to in a pinch, but I'd prefer not to have to owe them a favour), but I do have access to a MESH test environment, so I can check how it responds to various inputs.

So far as I can tell, MESH will accept any token, so long as the combination of nonce, nonce count, and timestamp, is unique (and the signature checks out). It doesn't appear to validate that any of these things are within a given range, monotonic, or even well-formed - indeed, it seems that I may have been overzealous with my validation in https://github.com/jamespic/fake-mesh, since MESH itself does not validate this at all.

The one thing I would wonder is whether it's used for something internally, which doesn't affect requests but does potentially mess with MESH's internal book-keeping. One thing I found with Fake MESH (which is a clean-room implementation of the same API) was that if you kept track of which nonces had been used in a database, that database could grow big enough to be a problem if you were using it at high enough volume in performance tests (which I keep meaning to put a mechanism into Fake MESH to handle). So I wouldn't be surprised if real MESH had some sort of cleanup job that deletes old nonces from the database based on timestamps. And I also wouldn't be surprised if it could potentially be thrown off by the use of distant-past, distant-future, or malformed timestamps. It's certainly my experience that the MESH team often choose not to implement input validation, and instead rely on putting potential integrators through a rigorous quality assurance regimen, to ensure they don't send any invalid input.

So I may change this to utcnow if I get some time, but I don't believe this will break right now, even if you are in a far off timezone.

[jamespic]

I realised after writing the previous comment that I do have one authoritative source of information on this: The official MESH client. I don't have the source to it, but it decompiles cleanly, so I can see it uses local timestamps.

I'm unsure what to conclude from this though, beyond that they do not validate timestamps and have probably not considered how they would do so.

[wvh]

Thanks for your elaboration!

I remembered reading something about token timeouts in the API description:

the server will reject the request if the timestamp supplied is not within 2 hours of the server time

I know some of our servers are located in different time zones, possibly with all sorts of wonderfully different TZ settings. Probably would be a good idea to make sure servers accessing MESH are using UTC then, to be on the safe side...

[jamespic]

I spoke to my contacts in the MESH team, and the intention was apparently for this to be UTC, even though the Java client uses local time, and the timestamp isn't checked for anything but uniqueness internally. I'll get a change in to make this UTC.