Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Trying to work out the rule from the outside. These are all accepted as literals:
auth:
tokenUrl: https://id.example.com/oauth/token
passwordSelector: "#password"
tokenPlacement: { kind: header, name: Authorization }This is rejected:
vars:
standardPassword: secret_sauceSo it is not an exact-name list and it is not a "contains password" list either. What is it?
Accepted answer
It is a case-insensitive substring match with a short exemption list on the suffix.
A key is treated as secret if its name contains any of password, secret, token, apiKey, api_key, clientSecret or client_secret. Substring, so standardPassword and refreshToken match as surely as password does — which is the point, since renaming the key was the obvious way around it.
It is then exempted if the name ends in url, env, selector or placement. That is exactly your three: tokenUrl is an endpoint, tokenEnv is a variable name, passwordSelector is a CSS selector, tokenPlacement is a structure. None of them can hold a credential, so requiring ${VAR} there would be noise.
An empty string is also allowed, so token: "" passes.
Consequence worth spelling out: the integrations and MCP sections store the names of variables rather than their values, and the field names say so — tokenEnv, emailEnv, envFrom, headersFrom. If you find yourself wanting to put a value in one of those, you have the wrong field.
Same name pattern drives redaction elsewhere, so a key you name apiKey is masked in config show output and in the logs whether or not its value is a reference. Naming a non-secret field sessionToken will get it starred out in places you did not expect.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.