0.8 final spec (98% compliance) #66
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Following an auth request which uses a TokenDetails or TokenRequest object that contains an incompatible clientId, the library should in the case of Realtime change the connection state to FAILED and emit an error, and in the case of REST raise an exception
* RSA15b - If the clientId from TokenDetails or connectionDetails contains only a wildcard string'*', then the client is permitted to be either unauthenticated (effectively anonymous without a clientId) or authenticated providing a clientId when communicating with Ably * RSA15a - Any clientId provided in ClientOptions must match any non null clientId value inTokenDetails or connectionDetails of the CONNECTED ProtocolMessage, where applicable * CD1 - Connection details are optionally passed to the client library in the CONNECTED ProtocolMessage#connectionDetails attribute to inform the client about any constraints it should adhere to, and provide additional metadata about the connection. For example, if a request is made to publish a message that exceeds the maxMessageSize, the client library can reject the message immediately, without communicating with the Ably service * CD2* - ConnectionDetail attributes
Token strings do not have any metadata such as client_id, so authentication with a token string is not a means to validate a client_id
* Configurable realtime disconnected & suspended retry timeouts (see TO3l1 & TO3l2) + other undocumented realtime configuration, see DF1* * Changing to suspended state no longer triggers an immediate reconnect attempt, only transitions to disconnected for the first time * Various fixes to connection state handling, suspended state is perpetual now in all cases * Fix bug in subsequent recurring authorisations * Improved handling of token expiration and connection state recovery
By providing this new predicate method #client_id_confirmed?, publishing of messages can be rejected early if the client_id is not compatible. This commit lays the groundwork for that.
mattheworiordan
force-pushed
the
0.8-final-spec
branch
from
9b173ee
to
5eb7916
Compare
mattheworiordan
force-pushed
the
0.8-final-spec
branch
from
021178d
to
1b1a039
Compare
mattheworiordan
added a commit
to ably/docs
that referenced
this pull request
Nov 18, 2015
Addresses issue whereby a client authenticated with a wildcard clientId value (indicating any clientId can be assumed), is not reflected to anyone observing the client i.e. Auth#clientId is null, yet Auth#clientId is also null when a client is anonymous. Addresses realtime issue #349 and wiki issue #31 See ably/ably-ruby#66 for this issue discovered in ably-ruby
mattheworiordan
added a commit
to ably/docs
that referenced
this pull request
Nov 20, 2015
Addresses issue whereby a client authenticated with a wildcard clientId value (indicating any clientId can be assumed), is not reflected to anyone observing the client i.e. Auth#clientId is null, yet Auth#clientId is also null when a client is anonymous. Addresses realtime issue #349 and wiki issue #31 See ably/ably-ruby#66 for this issue discovered in ably-ruby
mattheworiordan
added a commit
to ably/docs
that referenced
this pull request
Nov 20, 2015
Addresses issue whereby a client authenticated with a wildcard clientId value (indicating any clientId can be assumed), is not reflected to anyone observing the client i.e. Auth#clientId is null, yet Auth#clientId is also null when a client is anonymous. Addresses realtime issue #349 and wiki issue #31 See ably/ably-ruby#66 for this issue discovered in ably-ruby
mattheworiordan
added a commit
that referenced
this pull request
Dec 2, 2015
0.8 final spec (98% compliance)
QuintinWillison
pushed a commit
to ably/specification
that referenced
this pull request
Sep 20, 2022
Addresses issue whereby a client authenticated with a wildcard clientId value (indicating any clientId can be assumed), is not reflected to anyone observing the client i.e. Auth#clientId is null, yet Auth#clientId is also null when a client is anonymous. Addresses realtime issue #349 and wiki issue #31 See ably/ably-ruby#66 for this issue discovered in ably-ruby
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@SimonWoolf and @paddybyers, over the last 2-3 days I have brought the Ruby spec up to date with the 0.8 spec, see https://docs.google.com/spreadsheets/d/11fxeoCsaW1j5Q5VWtFNf04v6LXFYoHRhVTRgsEysZkU/edit#gid=431008744. Ruby complies with 98% of the specs, which I think is good enough for now. It was a good exercise to ensure the spec is practically implementable - as you will see in https://github.com/ably/docs/commits/source, there are a few commits I have modified to fix some issues I found along the way.
I have in fact implemented https://github.com/ably/wiki/issues/31, however it is somewhat blocked by https://github.com/ably/realtime/issues/349. I would really like to get https://github.com/ably/realtime/issues/349 addressed if possible, so long as it is indeed easy to implement.
I will now focus my attention on completing documentation as the implemented spec in Ruby, even if not adhered to correctly in all client libraries, is good enough to work with.
FYI @lmars if you're interested...