SonarCloud tokens do not end up revoked without user action (SonarSource isn’t revoking any tokens on behalf of users), and there have been no deployments related to API authorization or these API endpoints.
GET api/projects/search requires Administer Organization permissions on the organization. This has always been the case. If the permissions are assigned to specific groups instead of individual users, it may be worth checking that group membership has not changed.
I think the best debugging steps you could do would be printing the full URL that is being queried (to make sure it’s expected) as well as the value used for sonar.login (to make sure it’s the one you expect – the new token).
Thanks Colin to pointing me to a right direction. Indeed the tocken was a different one… after digging through tons of audit logs (btw. for azure devops the link is Azure DevOps Services | Sign In & it can be exported to Azure Monitor and more…) I have found out the connection was modified by one of my colleague in parallel… that’s what has confused me tbh.
So sorry for filling up this bug & wasting your time while the issue was on our side. And really thanks a lot for helping me.
Anyway one question is still valid: is there any public information about a version (and release date/when it was deployed, release notes…) so we can eliminate server side changes/updates in the future?
It’s a valid question and also valid feedback which I’m happy to pass along. Here’s my honest take on it right now:
We don’t deploy “versions” of SonarCloud — we continuously merge and deploy changes to SonarCloud. When there are big changes (new features, deprecations, requirements changes, etc.) we announce them. Our general issue tracker (bugs/improvements/deployments) is internal.
This works pretty well as is. Can you honestly tell me that if such detailed notes were available, and something went wrong without a good explanation, the question wouldn’t become “what’s missing from the release notes”?
Personally (taking my SonarSourcer hat off), I wish we had a way of helping users know what changed on SonarCloud since yesterday, even if it’s the small stuff (as a user of other cloud services, I know I care about the small stuff sometimes!)
Not sure, if this is something “built-in” in Azure DevOps or if this is something you as SonarSource as author of the service connection type can fix maybe?
Context: SonarCloud is shared service connection. Unfortunatelly it can not be shared “for all projects”, you need to assign it project per project. So yesterday colleague of mine was sharing the connection to some newly created project. Nother unfortunate thing is that the name of the connection is changed to “SonarCloud - NewProject” …while my colleague was trying to fix this (actually only changing the name of the connection) and saving it in the scope of the new project, he fails to “verify it”…so he saved it without verification… this process changed the token from real token to ‘****’ which was ofc not valid…