As with my other post today this comes about due to the recent issue over at CircleCI.
Can we please have the Web interface and the CLI interface place provide a useable reduced-length version of a defined/used Service Token.
Currently
- Web interface provided no way to validate a used token against a generated token.
- The CLI has been coded to just show the first few characters of a token, regardless of how many characters are needed to make the value shown useful.
The name of a token currently seems to be
<dp.st><config name><unique ID>
So the first part is not really of any use to me and the last part is just a random string. This leaves me with just the middle part to search for, but having just the config name is not that helpful as while I can search for a config in the web GUI I have no way to tie the Token to an issued Service Token, unless I start using the CLI tool to cause a login and so cause the last used field to update.
It would be very helpful if both the Web interface and CLI correctly showed part of the value allocated to a Service Token up to and including the first 6 characters of the unique ID. It should also be possible to search for this short ‘value’.
We’re looking at some ways to help make finding the correct token when you only have the token value easier. For example, some ideas we’ve had are an API endpoint that will provide the token slug for the token making the request (which you could then use with doppler configs tokens revoke) and could include information like the project and config the token belongs to.
Another thing we’re going to be adding in the very near term is a token preview column to the service tokens table in the dashboard. The Personal and Audit token tabs already show this preview and we plan to add this to the CLI and Access Token tabs early next week to help with this. Once that’s in place, you can determine which project and config the token belongs to by doing a doppler secrets --only-names --token $TOKEN_IN_QUESTION_HERE | grep DOPPLER and then can find the token by matching the last few characters of the token.
In the mean time, a workaround for this is to perform a full request using the token (e.g., doppler secrets --token $TOKEN_IN_QUESTION_HERE | grep DOPPLER – don’t use the --only-names flag). After doing that, go to the project+config you see in the DOPPLER_ secrets and look at the Access Logs tab. You’ll see a new entry for the token that includes the token preview and the name of the token. You can then use that token name to find it in the Access tab to revoke it.
I know these workarounds aren’t great, but hopefully they’ll help until we have a better solution in place.
