Configure Your Environment

Setup an SSH Key for Git

CodeScene operates on local clones of your Git repositories. CodeScene does an automated git pull before an analyses, which lets you see the latest changes reflected in your analysis results. This means you need to grant CodeScene access to your repository origins. You do that by providing an SSH key (see for example https://git-scm.com/book/be/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key).

When using the empear/codescene docker image, you will find instructions for settings up ssh on Docker Hub. .

NOTE: If you chose to run CodeScene in Tomcat, the SSH key has to be associated with the Tomcat user since that’s the user who will access the Git repositories.

Using Basic Authentication for Git

Using an SSH key is the preferred alternative.

Another option is to use basic authentication with username and password set in the git clone URL for every CodeScene project, e.g. https://user:password@github.com/my-org/my-repo.git.

This is less secure and not recommended as a default option.

Persistent Authentication Sessions

CodeScene stores user sessions in memory which means that users have to log in every time the application process is restarted.

Sometimes, it can be useful to avoid re-authentication, especially when you run CodeScene under a system user for monitoring purposes (Dashboard view).

In that case, you can turn on “persistent” authentication via browser cookies by setting AUTH_SESSION__ENCRYPTION_KEY environment variable. Encryption keys must be 16 characters long! User session stays valid for 14 days. If you want to change this interval, you do so via AUTH_SESSION__MAX_AGE_SECONDS environment variable.

# by setting encryption key you make users sessions persistent across restarts
export AUTH_SESSION__ENCRYPTION_KEY="1234567890abcdef"

# optionally, you can change max-age too
export AUTH_SESSION__MAX_AGE_SECONDS=120

Set up a Proxy Server

If CodeScene is running behind a proxy server, you might need to specify the proper configuration.

Whenever you’re trying to login or activate the license, Codescene contacts the license server to check if the license is valid and to update license limitations.

Without the correct proxy configuration, CodeScene won’t be able to check the license and update the license limitations in case they were changed on the server and will show an error message (unless you’re in offline mode - more on that later).

The user can provide the proxy configuration when logging in. If the license check is successful and the user is admin, the proxy configuration will be automatically saved in the global config for future connections.

Proxy Without Authentication

If you use a proxy server that does not require authentication, CodeScene might be able to automatically detect the configuration based on your operating system settings. You can always check the current proxy configuration in Configuration -> License -> Proxy Server.

Proxy with Basic authentication

If your proxy server is configured to use Basic authentication, you need to provide a username and password. Please, fill in the ‘User’ and ‘Password’ fields in Configuration -> License -> Proxy Server.

Proxy with Kerberos Authentication

CodeScene supports proxy servers with Kerberos authentication.

As long as you have a valid TGT ticket in your system’s Credentials Cache, CodeScene should be able to authenticate with your Proxy Server.

This is usually done with kinit command:

kinit <principal_name>

However, TGT tickets have limited validity (usually 24 hours). If you aren’t able to refresh them automatically, you need to specify the username (principal) and password in Configuration -> License -> Proxy Server.

If you don’t want to store username/password in CodeScene you can also create a keytab file and specify it in login.conf in CodeScene root folder as follows (make sure to put proper principal and keyTab file path):

com.sun.security.jgss.initiate {
  com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true doNotPrompt=false refreshKrb5Config=true
  principal=codescene useKeyTab=true keyTab=codescene.keytab;
};
com.sun.security.jgss.accept {
  com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true doNotPrompt=false refreshKrb5Config=true
  principal=codescene useKeyTab=true keyTab=codescene.keytab;
};

You can learn more about using Kerberos in Java applications here: Use of Java GSS-API for Secure Message Exchanges Without JAAS Programming:.

Other Authentication Mechanisms

If you’re using another proxy authentication mechanism and you’re not able to make it work with CodeScene, please let us know. We’ll do our best to add support for this authentication mechanism to CodeScene.

Offline Mode

If you are unable to provide a proper proxy configuration, you don’t want to let Codescene reach the Internet, or you simply don’t have an Internet connection for a limited period of time, you still may run CodeScene in offline mode.

If CodeScene is unable to activate its license or verify the user’s login, it will show an error message with a checkbox for activating offline mode. Administrators can also turn on offline mode globally in Configuration.

Offline mode is limited to the period of the current subscription term (billing period). When your current billing period ends, CodeScene needs Internet access to verify your license. If you need to run in offline mode for an extended period of time, you will have to pay for the whole period in advance.

Please note that offline mode should be regarded as an exceptional use case, either for emergencies or situations with specific needs. To ensure a smooth experience, users are encouraged to provide proper configuration. Please contact us if you need more help with network/proxy configuration.

Connection Timeouts

By default, CodeScene uses a 5000 ms timeout for both connection timeout and socket timeout. You can customize these settings with the LICENSE_CHECK_CONN_TIMEOUT and LICENSE_CHECK_SO_TIMEOUT environment variables. This can be useful if you’re running CodeScene in a high-latency environment or in permanent offline mode.

You can also enforce a hard timeout on the whole duration of license check request with LICENSE_CHECK_TOTAL_TIMEOUT environment variable. If you don’t specify total timeout computed value 1.5 * (connection timeout + socket timeout) is used as a default. Total timeout gives you a complete control over the license check duration. You cannot achieve this using just connection timeout and/or socket timeout. The main difference is in inability to control DNS resolution time using either connection or socket timeout.