Skip to content
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 12 commits into from
Apr 23, 2015
Merged

Token naming refactor #29

merged 12 commits into from
Apr 23, 2015

Conversation

mattheworiordan
Copy link
Member

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

@mattheworiordan
Copy link
Member Author

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?

@mattheworiordan mattheworiordan force-pushed the token-naming-refactor branch 2 times, most recently from a26c75d to 38189f5 Compare April 22, 2015 09:24
* 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.
@mattheworiordan mattheworiordan merged commit 93ce7e5 into master Apr 23, 2015
@mattheworiordan mattheworiordan deleted the token-naming-refactor branch November 4, 2015 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant