-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Token naming refactor #29
Merged
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
BTW. 4425f4e...token-naming-refactor contains the commits for this PR as until_attach PR is not merged yet. Can you please feedback on that too so that I can merge if you are happy? |
a26c75d
to
38189f5
Compare
* Token class is actually TokenDetails and contains a #token string that is the token itself * Auth#current_token is in fact a TokenDetail object so renamed to current_token-details * Auth#token_id has become Auth#token for clarity, where a token is referenced it is always a token string * key_id is now always referred to as key_name internally, with the exception of the client library constructors (to be reviewed later). * capability is exposed as a JSON object instead of a JSON string to
* Return a TokenRequest object for all create_token_request request * Support the use of JSON TokenRequest, JSON TokenDetails or a token string for :auth_url response. Token string requires a text/plain mime type * Auth block can accept TokenDetails or TokenDetails JSON, TokenRequest or a token string
* key_id & key_secret are no longer documented options * key_name & key_secret are still supported by undocumented as internally keys are split into those parts anyway * legacy :api_key option is gone
* :token string is supported & documented * :token or :token_details can contain a TokenDetails object
* All attributes are now in milliseconds whether to represent a period of time (ttl) or a time in milliseconds since epoch * Where objects in Ruby represent data structures returned directly from Ably for the purposes of Authentication, milliseconds is always used, although a Time object can be used as well. Not mixing seconds & milliseconds ensures that JSON objects are interchangeable with typed objects in the case of TokenRequest and TokenDetails objects. * key name is now always referred to as `key_name` * token string is now always referred to as `token` * requestToken always returned a flattened TokenDetails JSON object * Realtime authentication uses key (an entire API key string) as opposed to the key parts. Other than token requests where the secret part of the key must not be exposed, the key is treated opaquely as a single string.
6ed4073
to
93ce7e5
Compare
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.
This PR tackles all the refactoring discussed in ably/ably-js#33 (comment) with the exception that any field name or type changes on the server-side have not been changed but instead have been marked with
TODO
.@kouno and @paddybyers I believe this covers pretty much everything so can be used as the basis for discussions with client library developers in regards to supporting this updated API.
We should discuss the few remaining points starting at ably/ably-js#33 (comment) so that we can hopefully finalise and lock down the API now.
I've just realised that this list of commits includes the
until_attach
PR, so the changes for this PR only are in 4425f4e...token-naming-refactor