-
Notifications
You must be signed in to change notification settings - Fork 41
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 default for clientId is Null #59
Conversation
I agree that wildcard should not be automatic. If a token is requested without any clientId specified, then it's anonymous. |
@paddybyers you happy with the proposed defaultTokenParams attribute though as I believe we'll need it to address the shortcoming of a default |
Much as I dislike the sprawling complexity of the API, I don't see another solution. |
Ok, I'll wait for @SimonWoolf thoughts before merging |
👍. I do think this makes (I've no strong opinion on whether client libs should hold defaults for ttl & capability, so I'll stay out of that discussion) |
Revisions can be made by anyone, so ensure we always link to the version we’ve created
This solves one problem for a developer whereby they can now specify a clientId wildcard token and useTokenAuth so that the client library automatically allows any clientId to be used without actually having assumed a clientId
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
When versioning is implemented, it will ensure that the REST API provides consistent defaults
09d8aa3
to
0df827a
Compare
This has been merged in... |
The current spec presents an issue for developers that want to authenticate with a wildcard clientId and want the client library to automatically perform this auth for them.
For example, when instancing a library, if specifying
useTokenAuth: true
, the client will currently always be either an anonymous client (if we assumedclientId
defaults tonull
), or a wildcard client (assumingclientId
defaults to*
). I do not think we should be encouraging people to use a wildcardclientId
by default, so I propose we:clientId
tonull
(anonymous) unless specfiedTokenParams
for the client library in theClientOptions
@paddybyers @SimonWoolf WDYT?