LGTM Enterprise 1.22.2

Controlling access to content

The content in LGTM is derived from code repositories. You define one or more repository providers, and then add code repositories to LGTM for analysis. Any successfully analyzed codebases are added as LGTM projects. For more information, see Defining integrations.

Controlling the default access for projects

The default access to each LGTM project is controlled by the associated repository provider. When you add a repository provider, you choose an authorization provider:

  • Public—all users can view all the information for projects created using this repository provider.

    For public projects, the full authorization level is used by default.

  • Private—all users can view limited information for the projects created using this repository provider.

    For private projects, the restricted authorization level is used by default.

  • External authorization provider—the project is treated as: public for users with access to the underlying repository, and private for users with no access. This uses authorization information from the external system—for example, Bitbucket Server or GitHub Enterprise. For more information, see Adding authorization providers

While you may want to restrict access to a few critical codebases, we recommend that you think carefully before routinely restricting access. LGTM Enterprise is designed to improve the development process by providing all users with the data they need to make decisions. Every time you restrict access to a resource, you reduce the pool of data available for decision making.

Overriding the default access for specific users

You can override the default access for an LGTM project by defining user-specific authorization rules using the Users administration page. This is particularly useful for managers and other users who don't have an account for an external system, but who need to see the related projects.

User-specific rules act on one of the following scopes:

  • Global—overrides the authorization for all projects, from all repository providers.
  • Repository-level—overrides the authorization for all projects generated from repositories hosted by one repository provider.
  • Project-level—overrides the authorization for one project.

You define rules and specify the level of authorization to apply to that scope, one of: full, restricted or hidden. When you define a user-specific rule, it overrides the default access for that user for the specified scope. For more information, see Managing user-specific rules.

Overriding the behavior for private projects

For users without full access to a project, the restricted authorization level is suitable for all but the most sensitive codebases. However, in some systems you might need to hide all information about private projects from users who don't normally have access to those codebases. If this is required, you can override the behavior for private projects globally using the Settings administration page.

To hide all information about private projects from unauthorized users, display the Settings administration page and enable the Completely hide private projects option. For an example of how this affects the data displayed to users, see About authorization levels.


Company X uses GitHub Enterprise to host most of their repositories. They also have a few Subversion repositories. All developers have accounts for GitHub Enterprise and they have read-access to most repositories. The only GitHub Enterprise repository with restricted access is the Security project, which is visible only to Jane and John.

Initial set up

On the Integrations page, you (the LGTM application administrator) create:

  1. An authentication provider for GitHub Enterprise, allowing developers to access LGTM using their existing GitHub Enterprise accounts.
  2. An authorization provider for GitHub Enterprise, enabling LGTM to use details of repository access from GitHub Enterprise.
  3. Two repository providers:
    • GitHub Enterprise which they configure to use the GitHub Enterprise authorization provider, so that LGTM respects the read permissions defined in GitHub Enterprise.
    • Subversion which they configure to use the Public authorization provider.

This setup configures LGTM access for all of Company X's repositories. It results in the following permissions being granted, based on the information LGTM receives from the providers:

User Project Authorization level Reason
Jane and John All GitHub Enterprise projects Full Settings in GitHub Enterprise give Jane and John read access for all projects
Any developer (apart from Jane and John) Security project Restricted These users don't have read access for this project in GitHub Enterprise
Any developer Any GitHub Enterprise project except Security Full Settings in GitHub Enterprise give all developers read access for these projects
Other employees All GitHub Enterprise projects Restricted They have no accounts for GitHub Enterprise, and so have no read access
All users All Subversion projects Full Access is defined as public.

This assumes that you have created LGTM login accounts for the users described in the table above as "other employees," or that your have set up LGTM Enterprise to allow users to access content without logging in (see Unauthenticated access to lgtm).

Fine-tuning the access

With the default configuration, most LGTM users can view the full data for the codebases that they're interested in. However, the CTO needs to see the full data for all projects.

To configure this:

  1. On the Users page, find the CTO's LGTM user account.

  2. In the Authorizations column, click the Update link to display this user's authorizations page.
  3. For the "global authorization" rule, click FULL to apply the Full authorization level across all projects for this user.

This rule overrides the CTO's default access so that she/he can now see all the data for all projects, even the Security project.

Related topicsRelated topics