-
Notifications
You must be signed in to change notification settings - Fork 55
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
CipherParams conform to latest spec (separate algorithm and keyLength) #120
Conversation
I think the spec is missing the point a bit of the So this is why we've got So we're confusing the portability of the arguments you might supply to get a I agree that the fixtures should have |
I'm fine with merging this PR but in the light of the comment above do you think anything needs to change in the spec? |
In that case, possible spec tweak:
Still not very happy with the CipherParams atm -- https://github.com/ably/ably-js/blob/master/browser/lib/util/crypto.js#L100 says people may instance a CipherParams directly and populate it themselves, but that's currently broken in node ( |
Yes, I think that's a consequence of how we're aggregating the different contexts into the node lib. I think that whole Re your spec changes: keylength defaults are algorithm-specific. 128 is the default for AES. It's not true that keyLength is meaningful for all algorithms, but it's nearly always meaningful so I'm ok to keep it as a standard property. |
b48cb0e
to
72fcc4a
Compare
Cool, added that to the PR. |
CipherParams conform to latest spec (separate algorithm and keyLength)
Thanks. Will you raise a docs issue for that spec question? |
|
Per http://docs.ably.io/client-lib-development-guide/features/. (Also makes it align better with cipher params options on the fixtures, which all have separate
algorithm
andkeylength
entries. (though annoyingly they usekeylength
rather thankeyLength
, so aren't quite valid CipherParams objects.))@paddybyers what's the logic behind cipherParams being required to be an instance of a
CipherParams
object (with no behaviour) when egtokenParams
can be a plain object?Also I'm a bit puzzled by the error thrown when it isn't a CipherParams -- "ChannelOptions not supported". It's true that we don't yet support passing channelOptions when getting a channel (you need to call setOptions), but isn't that independent of what kind of object cipherParams should be?
Edit: also, for some reason cipherParams created in a test using
new Crypto.CipherParams
are failing theparams instanceof CipherParams
test in nodejs. (Though working as expected in a browser).