LGTM Enterprise 1.23.1

About authorization levels

Access to information is governed at the level of a user's right to view individual LGTM projects. Each project contains information derived from one repository. The amount of information about a project that's displayed to a specific user is defined by one of three authorization levels: full, restricted, or hidden. For more information, see Controlling access to content.

Information provided by integrated systems

Most integrations provide detailed authorization information. They report details of the repositories that are visible to each user with an account in the external system. This includes any public repositories, and all private repositories that the user has at least read access to. By default, integrations are configured so that when a user logs in to LGTM using their external account, they have full access to any LGTM projects created for repositories they can access in the external system.

When a user does not have access to a repository in the external system, the resulting LGTM projects are treated as private projects. The user's default authorization level for these projects is restricted. Projects are also treated as private for users who do not have an account with the external system, or who log in to LGTM using a different account.

Full authorization

When a user has full authorization for a project, they can see all of the information available for the project in LGTM. This includes the source code, alerts, metrics, custom query results, etc. A user has full authorization to view all of the data for a project if any of the following is true:

  1. The project is public for all users. The integration that provides access to the repository specifies the public authorization mechanism.
  2. The project is public for this user. The integration that provides access to the underlying repository uses the repository host to provide authorization information, and the user has access to the repository in this system. The user must be logged in to LGTM with an appropriate account.
  3. An administrator adds a rule for the user to provide full access to the project.

Restricted authorization

When a user doesn't have full authorization for a project, they usually see a limited set of metrics. This includes: number of lines of code, number of alerts, and number of alerts fixed, but does not include the project name or source code. A user has restricted authorization to view data for a project if:

  1. The project is private and access is restricted for all users. The integration that provides access to the repository specifies the private authorization mechanism.
  2. The project is private and access is restricted for this user. The integration that provides access to the underlying repository uses the repository host to provide authorization information, and the user has no access to the repository in this system. Alternatively, they may be logged in with a different account and are therefore unknown to the repository host.
  3. An administrator adds a rule for the user to provide restricted access to the project.

Hidden authorization

This is not used in a default installation of LGTM Enterprise. This level of authorization provides no access to information for a project, not even the existence of the affected project. It is provided in case you have a highly sensitive codebase which must be hidden from almost all users. A user has hidden authorization to view data for a project if:

  1. An administrator has enabled the global setting Completely hide private projects, the project is private, and access is restricted for this user. This overrides the restricted authorization provided by points 1 and 2 in the Restricted authorization section above. It does not affect users where an administrator has defined a rule to give them restricted access to a project.
  2. An administrator adds a rule for the user to specify hidden access to the project.

Impact on user views

All views visible to standard users respect the authorization rules and integrations that apply to the current user. The guiding principle is that the site must give a consistent experience to all users, regardless of their authorization level for different projects.

Where consistency cannot be maintained without violating authorization restrictions, all related data is omitted from the view. This ensures that developers with access to different projects see either the same information or no information.

For systems where some projects are defined as restricted or hidden, in practice this means that whole pages may be blocked, or parts of pages may be omitted for some users.

Example

Every user's profile page is subject to authorization concerns because it includes information about projects. When you view another user’s profile page, you will see a modified version of the page unless you have full access to all the projects that they contribute to.

The screen shots below are for an individual user's profile page—for example, the view you see if you search for someone and then click their name in the search results.

Full authorization for all projects

If you have full authorization for all of the projects the other developer contributes to, the profile page shows all data and might appear as follows.

Restricted authorization for some projects

If you have full authorization for most of the projects the other developer contributes to, but restricted authorization for the last three in the list above, the page is modified as shown below.

The graph is still displayed—showing sum totals of metrics, including values for projects that you have restricted access to. However, the final three rows of the table below the graph have been summarized as a single row of "Other projects," so that you can't see details for those projects.

Hidden authorization for some projects

If you have full authorization for most of the projects the other developer contributes to, but the last three projects in the list above are hidden from you, the page is modified as shown below.

The graph is no longer shown because it contains data from the hidden projects. The total commit, alert, and line counts for the profiled developer are also hidden. This ensures that you cannot determine how much work that developer has contributed to hidden projects.

The languages table shows only the languages contributed to projects that you have authorization to see, and no metrics. The table containing the per-project statistics is retained, but the three projects that are hidden from you are omitted entirely.

The absence of the graph, and the other changes, allows you to deduce that this person has worked on projects that are hidden from you, but you cannot tell any more than that.

Related topicsRelated topics