Default token params should not include a capabilities member

[SimonWoolf]

By default, if using token auth (e.g. because they've specified a clientId), the lib is requesting a token with capabilities of "{\"*\":[\"*\"]}", see https://github.com/ably/ably-ios/blob/master/Source/ARTTokenParams.m#L32

This is wrong: it fails if someone is using a key with capabilities restricted to a subset of channels. (The user gets a Key does not support requested capabilities error right after initializing the library, which is a pretty bad user experience).

When no capability is specified by the user in defaultTokenParams, the token request should be sent with no capability member.

(RSA6 may be misleading, I'll file a docs issue)

[mattheworiordan]

@SimonWoolf see https://github.com/ably/realtime/issues/780. I am not sure I agree that request is wrong TBH. This is a bit contentious.

[SimonWoolf]

@ricardopereira FYI: me Matt and Paddy discussed this (and Matt's concerns) today. We are going to put a workaround in realtime for this, and will be discussing deeper changes, but as far as iOS is concerned, this bug is correct, it should not be sending a capability member by default.

[funkyboy]

@SimonWoolf Is this still happening?

[SimonWoolf]

@funkyboy I don't have a mac so can't verify directly, but the code in question doesn't appear to have been changed since I submitted this issue, so I assume it is still happening.

It's not that big a problem since we rewrote capability intersection in realtime to be commutative. But ably-ios behaviour is still wrong per the spec -- https://docs.ably.io/client-lib-development-guide/features/#RSA6 -- so should be fixed.

[SimonWoolf]

@ricardopereira is there any update on this? This bug is two years old now, and is still causing customers problems from time to time.

Additionally, ably-ios is not properly encoding the capability in the query string e.g. &capability={%22*%22:%5B%22*%22%5D}&.... The braces aren't being encoded, when they should be.

Additionally, ably-ios is generating a timestamp and including it the querystring: &timestamp=1549468527.841610&format=.... This is wrong in three ways:

1. It's in seconds (per spec should be in milliseconds since the epoch),
2. It includes a fractional part (should be an integer number of milliseconds), and
3. It shouldn't be there at all: per the spec (RSA9d) the timestamp should be generated in createTokenRequest by the auth server, not by the requesting client. (For one thing, a requesting client is quite likely to have a time that's off by >2 minutes).