SonarLint authentication should match bound server policy

The wizard for binding SonarLint to a SonarQube server includes a step for entering a password/username combination or a security token. Without supplying one or the other you can’t complete the binding to the server. This is more restrictive than what my server enforces, where anyone can view code or submit code for analysis.

Why is SonarLint more restrictive that the server itself? One way or the other, they should match. Either both should require authentication to read issues and rules, or neither should.

And yes, I know I can create a token for a dummy/generic account to get past this, but what a poor solution that would be.

2 Likes

Sorry for the long delay on this thread. After new discussions in the team, we agreed that SonarQube anonymous binding should be allowed.
This is already possible in Visual Studio, so here are tickets for the 3 other flavors:

We will try to tackle them as soon as possible, but this is not very high priority so it may take a few weeks/months.

1 Like

It’s pretty obvious that this issue isn’t a high priority because it took ten months to receive a reply to this post.

Given how hard SonarLint is pushed on the community, it’s sad how bad the support has been in general for this product. I had to go the route of a using a dummy token, oh, ten months ago, because the 100+ developers I support wouldn’t wait for your fix. To this day I continue to be forced to provide this token to new developers, which costs my client time and money. Now it looks like that will be the norm for a “few weeks/months”.

I know it is a bit strange to come back on this topic after so long. I can share that this topic is highly debated internally, that is one of the reason it took us so long to reply.