As I’m using Doppler to drive ‘infrastructure as code’ deployments and CI builds the info placed in the logs is rather important for trying to understand why things have failed.
When “doppler configure set token” is run it does output some detail to the console/log to be helpful, but the info it provides does not help that much due to the way that it truncates the token. As an example here are 2 different tokens being used
┌───────┬──────────────────┬───────┐
│ NAME │ VALUE │ SCOPE │
├───────┼──────────────────┼───────┤
│ token │ dp.st.mac-…PDpT6 │ / │
└───────┴──────────────────┴───────┘
┌───────┬──────────────────┬───────┐
│ NAME │ VALUE │ SCOPE │
├───────┼──────────────────┼───────┤
│ token │ dp.st.mac-…09NzP │ / │
└───────┴──────────────────┴───────┘
So the token name is truncated to the first 10 characters + the last 5. Such a string has zero real value as
there is no way to work out from the first part which config is being referenced unless it has been given a very short name and I mean short as the name is a combination of both the ‘master’ config and its subordinate config.
the second part has been taken from the end of the token and logically is not something that someone should have easy access to as it is part of a secret.
It would be far more helpful if
The Doppler CLI displayed the token name starting from the beginning up until the 4th character of the secret key.
The Doppler GUI showed the same information as the CLI on the access (token) page.
This would mean that someone reading the logs would see info that allows them to validate that the correct config is being used, while also allowing them to easily check via the GUI that the config is still valid.
Generally speaking, we intentionally do not print the full token under most circumstances (unless you’re doing something like doppler configure get token --plain, which will print the full token). In other situations, this is done to avoid leaking the token in logs or elsewhere. If you’re trying to determine which config a service token is for, this is one of the reasons we automatically inject the DOPPLER_PROJECT, DOPPLER_ENVIRONMENT, and DOPPLER_CONFIG environment variables. You could update your automation to log the contents of those variables when executing and should get you most of the information you’re after.
If you’re trying to identify a specific token so you can delete it in Doppler, I’m afraid there isn’t really a good way to introspect a token to get that information currently. We have definitely discussed adding an endpoint that would pull that information though. Is deleting a token what you’re wanting to do here?
My request is not about showing the whole token but showing enough to allow someone viewing the logs to work out which token has been used. At the moment the detail shown does not allow that, you have to look at the source code of the script which may be under the control of someone else.
As an example one of my keys looks something like this
doppler configure set token --json $DOPPLER_TOKEN | jq -r '.[].token[0:-20]'
Using the --json flag will result in the full token and scope being printed. You’ll need to capture that and truncate it as seen above to ensure it doesn’t print the full token, but it should allow you to do what you want. Will that work for you?
I had created a workaround, not as clean as yours but with the same type of output as I just started with the env variable that was holding the token.
The issue is a workaround and it would make more sense for the client to provide more useful info in the logs and as I noted the web GUI to then allow that info to be looked up.
