TICS Viewer Configuration

This chapter explains the various configuration items for setting up and working with the TICS Viewer.

The TICS Viewer requires some bootstrap configuration to set up and get started. After you have a working TICS Viewer, it can be used to set other configuration options that further control the workings of TICSQServer and the viewer itself. We distinguish between TICSQServer and viewer configuration on one hand, and general and project-specific configuration on the other hand. The locations where the various configuration items can be found are:

Administration Pages

This section describes some of the settings that you find in the Administration pages. To access the Administration pages, you need to be logged in and you need to have the proper permissions. If that is the case, you will find the Administration pages in the application dropdown menu in the upper-left corner.

Authentication & Authorization

Authorization allows you to control which users have access to which projects and functionalities of the viewer. Users authenticate themselves using a username and password that they enter in the authentication dialog that is accessible through the padlock icon in the upper-right corner. The viewer supports two authentication services: built-in and LDAP. The built-in authentication service requires you to add each username and password manually. The LDAP authentication service is preferred because it is more scalable. If you already have an LDAP directory service running in your network, users can use the same credentials as they are used to. Users are automatically added when they first log in and can be authenticated using one of the configured LDAP queries. Even when using LDAP, you still might want to create some additional user accounts manually. One example is to create a functional account for a script that accesses the Web API. Another good practice is to create a (backup) administrator account that can be used when you are locked out, for instance when the LDAP service is (temporarily) unavailable, or when you made a change to the LDAP query that caused you to no longer have the proper permissions.

To use the built-in authentication service, create a user with a password on the Users page. In the user creation dialog, you can immediately choose the role that the user should receive. To use LDAP authentication, create one or more LDAP queries. A user is authenticated when it is accepted by at least one of the LDAP queries. You should create multiple LDAP queries if you want to assign different roles to different sets of users.

A role is simply a convenient name for a set of permissions. Example (built-in) roles are "Administrator", "Build Manager", and "User". Examples of permissions are the "administration" permission, which allows a user to access the Administration page and the "view project" permission, which allows a user to view metric data of a project. You can inspect or create new roles on the Roles page.

To assign roles to users, you need to create Authorization Rules. By default, a rule is created that assigns the "User" role to users that are not logged in (guests). To disable guest access, you should first delete this rule and then create one or more new rules. When creating a new rule, you need to select one or more users and a "project scope". The users can be an explicit set of users that you select from a list, or an implicit set of users that are accepted by an LDAP query. The project scope determines for which projects the user receives the permissions that are associated with the role. This is only relevant for project-specific permissions, such as the "view project" and "edit project" permissions.

By default, a user that does not have access to a project gets to see a padlock icon instead of the metric value. If you want to hide the project altogether, disable the "List unauthorized projects" setting on the Miscellaneous page.

Please refer to the Administration Pages for more in-depth information.

Firewall

Using the firewall settings you can block access to users based on their IP address. This provides an extra layer of protection on top of the authorization mechanism described above. The firewall supports IPv4 and IPv6 addresses, black- and whitelisting, and fine control over which functionality of the viewer should be blocked.

Please refer to the Firewall settings for more in-depth information.

Metric Presets

Metric presets are shortcuts to pre-configured sets of metrics. They are accessible from the Presets dropdown menu in the Explorer view. When selecting a preset in the Explorer, all existing metrics are replaced. In addition to metrics, a preset optionally sets one or more filters.

The TICS Viewer comes with a number of pre-configured metrics. You can change those or add new ones in Administration Pages → Metric Presets.

Quality Gates

A quality gate is a set of conditions that should hold before your software can pass to the next phase in the software development process. Each condition checks whether the current value of a metric is above or below a target threshold. An example of a condition is 'the number of Coding Standard Violations for level 1, 2, and 3 should be 0'.

You can define quality gates in Administration Pages → Quality Gates.

The quality gate statuses can be seen on the TQI Dashboard when you group by project or branch. A green or red flag behind the project determines whether the project passes or fails the gate. When no gate is associated with a project, no flag is shown. When an evaluation error occurred, an orange flag is shown, urging you to check the gate configuration. By clicking on the flag a dialog opens showing the evaluation result of each condition. Clicking on a condition shows you why the condition failed (or passed).

Quality gates statuses are evaluated dynamically by the viewer and are not stored in the database. This has advantage that when you create or change a quality gate, you can immediately see it's effect; projects that previously did not have a quality gate associated it now do, and passed projects might now fail and vice versa. This allows you to adjust the quality gate definitions and see the effect immediately. This also allows you to go back in time using the time machine functionality and inspect the status when the gate was not even defined yet.

Conditions can be evaluated (checked) per project (the default) or per file. When checking per file, every individual file should pass the condition.

Conditions can be absolute (the default) or relative. An absolute condition checks whether the metric value at the current date is above or below the target threshold. A relative condition checks whether the metric has changed a certain amount with respect to a chosen reference date, or in other words, whether the delta metric value is above or below the target threshold. An example of a relative condition is 'Δ Average Code Coverage ≥ 0', which specifies that the code coverage should increase with respect to the given reference date, which is configured in the binding as explained below.

When you create a quality gate, a default binding is created that binds the gate to global project scope. This means that the gate will be checked for every project configured in the viewer. If you only want some projects to be checked by the gate, you can specify a narrower scope in the binding.

In addition to the scope, you can also specify the delta reference date in the binding. This determines for relative conditions which date should be taken to compare the metric value with. These options include picking a specific date, a specific baseline name, the last baseline, the first analysis, or the previous analysis. Note that all options reference a static point in time, except for the 'previous analysis' which is dynamic: the reference date changes with each run. This could result in an unstable quality gate status: when the gate status goes to 'failed' because a developer introduced 5 issues, it will go to 'passed' when the next commit solves 1 issue. You can still see this in the history of the status, but you must take care not to ignore this information. Therefore, we recommend using one of the static reference dates where possible, or combine the dynamic reference date with a static one by creating two bindings.

Source Code Retrieval

After each analysis, TICSQServer uploads the source files that it analyzed to the viewer and removes any previously uploaded source files. This means that old revisions of source files are not readily available to the viewer. If you want to use the 'Diff' functionality in the Annotated Source, you need to enable Source Code Retrieval to be able to see old source file revisions.

The Source Code Retrieval is opt-in; it is disabled by default. You can enable it in Administration Pages → Source Code Retrieval. By default, the viewer will invoke TICSMaintenance on the Build Server (using TICS Build Service). The requirements for this default scenario are:

If these requirements are not met, you can configure the viewer to invoke a custom command on the viewer machine to retrieve source files. For instance, to configure the viewer to use Subversion over SSH, use the following settings:

Retrieve Old Sources
Yes
Execute on Viewer
Yes
Use Custom Command
Yes
Command
svn cat svn+ssh://user@192.168.1.1/path/to/svnrepository/$file@$revision
Environment Variables
SVN_SSH="C:/Program Files (x86)/Putty/plink.exe" -i "C:/Program Files (x86)/Putty/privatekey.ppk"

Please refer to the Source Code Retrieval settings for more in-depth information.

Configuring Sections

A default TICS installation only has one section, named TICS. When you access the viewer, you can see the section name in your browser's address bar. Sometimes you want to configure multiple sections, for instance, one for each business unit. Each section is isolated from the rest in the sense that it has its own set of projects and configuration. It is also possible for each section to run a distinct version of the viewer. This is useful for instance when you want to upgrade to a new version, but want to assess the impact of this upgrade on your TQI score, or first want to make sure that the new viewer is running correctly before you move it into production.

To configure a new section, you need to change the TIOBEPortal.cfg file. This JSON file is located in the webapps directory of your Tomcat installation, and look something likes this: 

{
  "TICS": {
    "root": "C:/Program Files/TIOBE/TICS/WebServer/TICS",
    "tiobewebServlet": "tiobeweb-9.0.1.34491"
  }
}

The root key points to a directory where the viewer stores various files such as data and settings. The tiobewebServlet points to the name of WAR file that contains the viewer "servlet". To create a new section, you are advised to first stop the Tomcat service. Then, duplicate the JSON object, change both the section name and the root directory. For instance, to create a new section "BU2" for a new business unit, the TIOBEPortal.cfg file will look like this: 

{
  "TICS": {
    "root": "C:/Program Files/TIOBE/TICS/WebServer/TICS",
    "tiobewebServlet": "tiobeweb-9.0.1.34491"
  },
  "BU2": {
    "root": "C:/Program Files/TIOBE/TICS/WebServer/BU2",
    "tiobewebServlet": "tiobeweb-9.0.1.34491"
  }  
}

After saving your changes, restart Tomcat, and access the BU2 section. You can do this by accessing your viewer's URL without a section, i.e. by accessing http://yourhostname:42506/tiobeweb. You will get a page with a list of configured sections.

It is possible to hide certain sections from this list. To achieve this, specify "hidden": true for the sections you want to hide from this list. If all sections are hidden but one, you are automatically forwarded to that section.

Configuring SSL/TLS

The TICS Viewer acts as both a server and a client in several communication channels, as depicted in the diagram below.

Most of these channels can be configured to use secure SSL/TLS communication. The TICS Viewer acts as a server (incoming arrows) in the following events:

In order to make the the above connections secure, you need to configure server-side SSL/TLS.

The TICS Viewer acts as a client (outgoing arrows) in the following events:

Server-side SSL/TLS

By configuring SSL/TLS you enable encrypted HTTPS communication between the TICS Viewer and its clients, such as browsers, which helps to prevent intruders from stealing sensitive data such as passwords. Because the TICS Viewer runs on Apache Tomcat, SSL/TLS can be configured through the Tomcat configuration files.

Alternatively, you can install a reverse proxy such a Nginx on a different machine or port number to encrypt traffic between the proxy and the browsers. Communication between the viewer and proxy can then remain unencrypted, so that you do not have to change the Tomcat configuration.

Server-side SSL using Tomcat configuration

To configure SSL in Tomcat, you first need to have a certificate. You can acquire one from a certificate authority (CA), or you can generate a self-signed certificate. In general, the downside of a self-signed certificate is that they are not trusted by default, and explicit configuration on the client side is typically needed. To generate a self-signed certificate, execute the following command and use changeit when prompted for the password: 

"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA -keystore c:/path/to/keystore.jks

Now add an HTTPS connector to conf/server.xml located in the Tomcat directory: 

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" 
   maxHttpHeaderSize="8192" SSLEnabled="true" 
   maxThreads="150" minSpareThreads="25" 
   enableLookups="false" disableUploadTimeout="true" 
   acceptCount="100" scheme="https" secure="true" 
   clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true" 
   keystorePass="changeit" 
   keystoreFile="c:/path/to/keystore.jks" 
   />

You need to restart the Tomcat service for the changes to take effect. Afterwards, you should be able to access the viewer on HTTPS on port 8443. Note that when using a self-signed certificate, your browser will indicate that the connection is not secure, because the browser does not trust self-signed certificates. This means that the connection is encrypted, but the server cannot be authenticated.

If you want to disable HTTP access, you can remove the default HTTP connector for port 42506 that was created by the setup. In case you migrate from a situation where the viewer was already running for some time and was accepting HTTP connections, and you now only want to support HTTPS connections, you can forward all requests so that existing links will not be broken. To do so, specify the redirectPort in the HTTP connector in server.xml as follows: 

<Connector connectionTimeout="20000" 
    port="42506" 
    protocol="HTTP/1.1" 
    redirectPort="8443"
    />

In conf/web.xml you have to include the following snippet inside <web-app>: 

<security-constraint>
    <web-resource-collection>
        <web-resource-name>HTTPSOnly</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>
Heads up! For some updates of the viewer, the TICS setup wants to update the Tomcat installation e.g. to fix a security vulnerability. Please make sure you have a backup of the conf/server.xml (and perhaps conf/web.xml), so that you can restore your configuration changes when they are overwritten by the defaults.

Client-side SSL/TLS for the TICS Viewer

In cases where the TICS Viewer acts as a client in communicating with other machines through SSL/TLS, and in case the certificate that the server uses is not signed by a root certificate that is trusted by Java by default, you need to add that certificate to the JRE's trust store (located in %JAVA_HOME%\lib\security\cacerts), using the keytool command that ships with Java and is located in %JAVA_HOME%\jre\bin.

If you have a certificate file (.cer, .crt) for instance, you would run: 

%JAVA_HOME%\bin\keytool -import -trustcacerts -alias "MyRootCA" -file my-certificate.crt -keystore %JAVA_HOME%\lib\security\cacerts -storepass changeit -noprompt

If you have a keystore file (.jks), you would invoke the following command: 

%JAVA_HOME%\bin\keytool -importkeystore -srckeystore my-keystore.jks -destkeystore %JAVA_HOME%\lib\security\cacerts -srcstorepass changeit -deststorepass changeit -noprompt

Please refer to the documentation of keytool for more details. The TICS viewer will pick up changes to the cacerts automatically: you do not need to restart Tomcat.

Heads up! The TICS setup sometimes updates the JRE that ships with TICS, but it will take care to merge the existing cacerts file with the new one, so that changes you made are not lost.

Client-side SSL/TLS for the Build Service

Each Build Server runs an executable named BuildServer.jar (wrapped by a service executable named TICSBuildService.exe on Windows) that connects to the viewer in order to receive commands that start a TICS analysis or change TICS configuration settings. When the viewer is configured to use SSL, build servers might need SSL configuration as well, depending on the type of the certificate authority (CA) that your certificate requires:

With respect to SSL/TLS, the Build Server offers the following configuration options that should be put in a file named TICSBuildServer.properties next to the BuildServer.jar file or in the directory pointed to by the TICS environment variable:

After each configuration change, please make sure to restart the service.

Configuring a Global TICS Viewer

A common scenario is to have one TICS Viewer per site within your company. Another scenario is that you have one TICS Viewer with multiple sections. In both cases, if you want to get an overall TQI score over all sections and sites, you need to set up a Global viewer. To configure a global viewer, create a new section in one of your viewers, and specify the option "global": true in the TIOBEPortal.cfg, as follows: 

  "global": {
    "root": "C:/Program Files/TIOBE/TICS/WebServer/Global",
    "tiobewebServlet": "tiobeweb-9.0.1.34491",
    "global": true
  }

Note that the name of the section can be chosen freely and does not need to be global.

Next, you need to point each regular 'local' viewer/section to the newly created global viewer/section. To this end, navigate to the Administration pages of each local viewer, click on the Miscellaneous tab, and enter the global viewer's URL, including the section in the Global Viewer URL input field. After you save the settings, the project data is sent from the local to the global viewer and the projects should appear automatically. The global viewer is automatically updated each time you add or remove a project or perform an analysis in a local viewer.

Compatibility

Configuring a viewer as a global viewer is supported starting from version 9.1. Configuring a viewer as a local viewer is supported starting from version 8.8. It is possible to have local viewers that are of a different version than the global viewer, however, the global viewer's version should (in general) be higher than all of the local viewer's versions.