Token default for clientId is Null

[mattheworiordan]

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 assumed clientId defaults to null), or a wildcard client (assuming clientId defaults to *). I do not think we should be encouraging people to use a wildcard clientId by default, so I propose we:

• Default clientId to null (anonymous) unless specfied
• We allow the developer to configure the default TokenParams for the client library in the ClientOptions

@paddybyers @SimonWoolf WDYT?

[paddybyers]

I agree that wildcard should not be automatic. If a token is requested without any clientId specified, then it's anonymous.

[mattheworiordan]

@paddybyers you happy with the proposed defaultTokenParams attribute though as I believe we'll need it to address the shortcoming of a default null clientId

[paddybyers]

you happy with the proposed defaultTokenParams attribute though as I believe we'll need it to address the shortcoming of a default null clientId

Much as I dislike the sprawling complexity of the API, I don't see another solution.

[mattheworiordan]

Ok, I'll wait for @SimonWoolf thoughts before merging

[SimonWoolf]

👍. I do think this makes useTokenAuth's behaviour a bit unexpected to someone who isn't very familiar with how our tokens work, but as long as we explain that in the docs for useTokenAuth (what to do if you want a token with the same permissions as you'd have using basic auth, ie defaultTokenParams: {clientId: '*'}), I guess that isn't a problem.

(I've no strong opinion on whether client libs should hold defaults for ttl & capability, so I'll stay out of that discussion)

[mattheworiordan]

This has been merged in...