Table of Contents
- Manage the permissions on your project
- Add a user to your project
- Personal token sharing
Manage the permissions on your project
When a project is created the default permissions are the following:
- it is private so that non authenticated visitors will not be able to see the project in the dashboard
- authenticated users can see the project in the dashboard, explore the metrics, but can't see the source code
- the user who has created the project through its first analysis becomes the administrator
We have chosen to let authenticated users see the project in the dashboard and explore metrics in order to show to the Inria community that developers follow good practices. We expect il will motivate users to do their best.
Of course the administrators of a project can always change this default behaviour in the Administration, Permissions panel of their project. For instance, one can remove the ability to any authenticated user to browse the project metrics. To do so, just uncheck Browse for sonar-users.
The project can also be made public to let any visitor see metrics and the source code, see the Administration, Permissions panel.
Add a user to your project
A project administer can add an user to a project. In the project page, go to the Administration tab then choose the Permissions section. Then search a user and specify the project-level permissions. Remember that only Inria members who have once connected to the sonarqube plateform will be visible.
Personal token sharing
The personal token is used to authenticate to the SonarQube server when a user wants to publish analysis results.
Recall the procedure to create a token:
- when logged in, go to "My account" (top right)
- select the Security tab
- generate a token
- copy the generated token (a 40 letters key) and store it
This token will be useful to authenticate to the instance replacing authentication with the login/password pair. It will be used for example as a secret variable on Gitlab or Jenkins, or directly stored on the machine performing analysis and tests (e.g. virtual machine).
Notice the token is per user, not per project. It is not supposed to be publicly available. Of course to automatize analysis in a CI (continuous integration) process one token will be used on some machines shared by administrators of the CI. It means you trust your collaborators of the CI project. As soon as you leave the project or if you don't trust your collaborators anymore you should revoke the personal token you used for this project. An advice: an Inria permanent member should create the personal token to avoid updating the token too often. In addition, one personal token per project should be created so that one can revoke a token related to a specific project without loosing the permission to publish reports on other projects.
This personal token sharing seems to be a weakness since several people can publish results in the name of one user. This is true. But it is the way SonarQube works... A solution could be to create some additional SonarQube accounts, one per project, to create non personal tokens. We don't want to come to that because:
this is a lot of additional administrative tasks (creation/destruction of fake accounts),
this solution just shift the problem. Several people may have access to the project's SonarQube account and add/revoke tokens so that the authenticity problem remains the same.