When creating a credential in Lightning, values the user does not set can still end up generating a key on the config object.
In commcare, it just happens that this breaks authorisation and the credential doesn't work in some cases. Lightning generates a config object like this:
Use any random values, but don't touch the apiKey field
Save the credential
Create a job which uses commcare and just does this:
fn((state) => {
console.log(state.data)
return state
})
You should see that the created credential sets apiKey to empty value, apiKey: "", even though we didn't ask for an API key
Adaptors note
This stuff probably doesn't usually matter, but it just so happens that commare does this:
if ('apiKey' in auth) {
Object.assign(headers, {
Authorization: `ApiKey ${auth.username}:${auth.apiKey}`,
});
} else if ('password' in auth) {
Object.assign(headers, makeBasicAuthHeader(auth.username, auth.password));
}
We could easily add a workaround in commcare to not use in. But I also think in is a reasonable pattern
The credential doesn't mark apiKey as required or set a default, so I don't know why this key gets set. Oh, it does set minLength, I don't know if that's part of the problem?
When creating a credential in Lightning, values the user does not set can still end up generating a key on the config object.
In commcare, it just happens that this breaks authorisation and the credential doesn't work in some cases. Lightning generates a config object like this:
To reproduce
You should see that the created credential sets
apiKey
to empty value,apiKey: ""
, even though we didn't ask for an API keyAdaptors note
This stuff probably doesn't usually matter, but it just so happens that commare does this:
We could easily add a workaround in commcare to not use
in
. But I also thinkin
is a reasonable patternThe credential doesn't mark
apiKey
as required or set a default, so I don't know why this key gets set. Oh, it does setminLength
, I don't know if that's part of the problem?