welcome
Out of curiosity, what’s the use case for that ?
Finally you may use a straight edit in Sonarqube database.
That’s what i used to change a bunch of projectnames, as this is not possible otherwise -
only the projectkey is editable.
That said, the Sonarqube database should be treated as a black box
A token was exposed (but not leaked) and revoking it is the right next step. Unfortunately we can’t trace the token back to any specific user account - all we have is the token.
Seems like a fairly typical if rare use case. Secret is exposed and needs to be revoked. Imagine a malicious attacker submitting reports and and all you have to go on are submissions. They won’t tell you their user name.
OK, the user_tokens table has only token_hash, but maybe you could identify it via
the last_connection_date !? If you use the token in question, it’s last_connection date will be updated.
Adam gave the answer I would have given, but after your reply I’ve checked the web services in 6.7.7 hoping that submitter was present in the web services even if not shown in the UI. It doesn’t seem to be there.
However, if I lift the veil on the-black-box-that-is-the-database I see a SUBMITTER_LOGIN column in the CE_ACTIVITY table. Maybe just this one time () you can look directly in the DB for what you need.
… or you could upgrade. This data is shown directly in the interface by 7.9, the latest version and current LTS.
Just for closure, in SonarQube 8.6+ you can call the api/user_tokens/search API with Basic Auth, specifying the token in the Username field.
The response contains the login that the token belongs to, and the response may contain more than one token.
In the case that there is more than one token associated with the account, you can figure out which token is which by looking at the lastConnectionDate field of the response; it will be set to the time of the api/user_tokens/search request.