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

createTokenRequest without key option #21

Closed
mattheworiordan opened this issue Mar 24, 2015 · 8 comments
Closed

createTokenRequest without key option #21

mattheworiordan opened this issue Mar 24, 2015 · 8 comments
Assignees
Labels
bug Something isn't working. It's clear that this does need to be fixed. enhancement New feature or improved functionality.

Comments

@mattheworiordan
Copy link
Member

In the Ably Ruby library when calling createTokenRequest, if an API key has been specified in the constructor, then there is no need to specify a key ID in the createTokenRequest method. Given most people will only issue tokens for the set up API key and we treat API keys as opaque (i.e. key ID is not really relevant), I recommend we change the createTokenRequest in the JS client library so that:

  • Passing in an empty hash is valid so long as Basic Auth is being used
  • instead of key_id & key_value options in the hash, we should really just support a key option.
@mattheworiordan mattheworiordan added bug Something isn't working. It's clear that this does need to be fixed. enhancement New feature or improved functionality. labels Mar 24, 2015
@mattheworiordan
Copy link
Member Author

I see also that the keyValue does not behave like it should in the documentation:

* - keyValue:      (optional) the secret value of the key; if not
     *                  specified, a key passed in constructing the Rest interface will be used; or
     *                  if no key is available, a token request callback or url will be used.

I get the error 'No key specified'

@mattheworiordan
Copy link
Member Author

One more issue, the token request Hash that is returned has a Hash object for the capability element, but it should be a Stringified JSON object. I believe if you receive a JSON capability the client library should be default Stringify it. Example request:

new Ably.Realtime({ key: apiKey }).auth.createTokenRequest(
        { keyId: keyId, keyValue: keyValue },
        { "ttl": 600, "capability": { "*":["*"] } }, function(token) {
          console.log(token);
        )

'{
  "id": "xVLyHw.lwnKYQ",
  "ttl": 600,
  "capability": {
    "*": [
      "*"
    ]
  },
  "timestamp": 1427235284,
  "nonce": "0452151051722466",
  "mac": "XslUpDsA5OQ7PSMKcrdb3IpMXNJg5VPXMyjVAgwsKyc="
}'

@paddybyers
Copy link
Member

Resolved

mattheworiordan added a commit to ably/docs that referenced this issue May 26, 2015
See ably/ably-js#21, which should mean this was not required
@mattheworiordan
Copy link
Member Author

I do not believe this is fixed unfortunately, see ably/docs@7c60e3b which I had to do now to get createTokenRequest to work. I was getting an error "missing key".

mattheworiordan added a commit to ably/docs that referenced this issue Jul 22, 2015
See ably/ably-js#21, which should mean this was not required
@mattheworiordan
Copy link
Member Author

See https://jsbin.ably.io/anadag/3/edit, this is not fixed.
Error is Error Error {message: "No key specified"}

@paddybyers
Copy link
Member

@SimonWoolf : could you have a look at this please?

@SimonWoolf
Copy link
Member

@mattheworiordan Addressed both in #83. Good spot re stringifying the createTokenRequest -- without that the capability part of the signText was just "[object Object]". (edit: removed inaccurate suggestion)

@paddybyers
Copy link
Member

Which I guess is only a security risk if realtime actually acts on capabilities given as objects rather than JSON strings

Hopefully ok:

https://github.com/ably/realtime/blob/master/common/lib/security/authmgr.js#L391-L392

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working. It's clear that this does need to be fixed. enhancement New feature or improved functionality.
Development

No branches or pull requests

3 participants