×

Overview

Administrators can customize the web console using extensions, which let you run scripts and load custom stylesheets when the web console loads. You can change the look and feel of nearly any aspect of the user interface in this way.

Loading Custom Scripts and Stylesheets

To add scripts and stylesheets, edit the master configuration file. The scripts and stylesheet files must exist on the Asset Server and are added with the following options:

assetConfig:
  ...
  extensionScripts:
    - /path/to/script1.js
    - /path/to/script2.js
    - ...
  extensionStylesheets:
    - /path/to/stylesheet1.css
    - /path/to/stylesheet2.css
    - ...

Relative paths are resolved relative to the master configuration file. To pick up configuration changes, restart the server.

Custom scripts and stylesheets are read once at server start time. To make developing extensions easier, you can reload scripts and stylesheets on every request by enabling development mode with the following setting:

assetConfig:
  ...
  extensionDevelopment: true

When set, the web console reloads any changes to existing extension script or stylesheet files when you refresh the page in your browser. You still must restart the server when adding new extension stylesheets or scripts, however. This setting is only recommended for testing changes and not for production.

The examples in the following sections show common ways you can customize the web console.

Additional extension examples are available in the OpenShift Origin repository on GitHub.

The following style changes the logo in the web console header:

#header-logo {
  background-image: url("https://www.example.com/images/logo.png");
  width: 190px;
  height: 20px;
}

Replace the example.com URL with a URL to an actual image, and adjust the width and height. The ideal height is 20px.

Save the style to a file (for example, logo.css) and add it to the master configuration file:

assetConfig:
  ...
  extensionStylesheets:
    - /path/to/logo.css

Links to external documentation are shown in various sections of the web console. The following example changes the URL for two given links to docs:

window.OPENSHIFT_CONSTANTS.HELP['get_started_cli']      = "https://example.com/doc1.html";
window.OPENSHIFT_CONSTANTS.HELP['basic_cli_operations'] = "https://example.com/doc2.html";

Save this script to a file (for example, help-links.js) and add it to the master configuration file:

assetConfig:
  ...
  extensionScripts:
    - /path/to/help-links.js

The About page in the web console provides download links for the command line interface (CLI) tools. These links can be configured by providing both the link text and URL, so that you can choose to point them directly to file packages, or to an external page that points to the actual packages.

For example, to point directly to packages that can be downloaded, where the link text is the package platform:

window.OPENSHIFT_CONSTANTS.CLI = {
  "Linux (32 bits)": "https://<cdn>/openshift-client-tools-linux-32bit.tar.gz",
  "Linux (64 bits)": "https://<cdn>/openshift-client-tools-linux-64bit.tar.gz",
  "Windows":         "https://<cdn>/openshift-client-tools-windows.zip",
  "Mac OS X":        "https://<cdn>/openshift-client-tools-mac.zip"
};

Alternatively, to point to a page that links the actual download packages, with the Latest Release link text:

window.OPENSHIFT_CONSTANTS.CLI = {
  "Latest Release": "https://<cdn>/openshift-client-tools/latest.html"
};

Save this script to a file (for example, cli-links.js) and add it to the master configuration file:

assetConfig:
  ...
  extensionScripts:
    - /path/to/cli-links.js

Serving Static Files

You can serve other files from the Asset Server as well. For example, you might want to make the CLI executable available for download from the web console or add images to use in a custom stylesheet.

Add the directory with the files you want using the following configuration option:

assetConfig:
  ...
  extensions:
    - name: images
      sourceDirectory: /path/to/my_images

The files under the /path/to/my_images directory will be available under the URL /<context>/extensions/images in the web console.

To reference these files from a stylesheet, you should generally use a relative path. For example:

#header-logo {
  background-image: url("../extensions/images/my-logo.png");
}

Enabling HTML5 Mode

The web console has a special mode for supporting certain static web applications that use the HTML5 history API:

assetConfig:
  ...
  extensions:
    - name: my_extension
      sourceDirectory: /path/to/myExtension
      html5Mode: true

Setting html5Mode to true enables two behaviors:

  1. Any request for a non-existent file under /<context>/extensions/my_extension/ instead serves /path/to/myExtension/index.html rather than a "404 Not Found" page.

  2. The element <base href="/"> will be rewritten in /path/to/myExtension/index.html to use the actual base depending on the asset configuration; only this exact string is rewritten.

This is needed for JavaScript frameworks such as AngularJS that require base to be set in index.html.

Customizing the Login Page

You can also change the login page, and the login provider selection page for the web console. Run the following commands to create templates you can modify:

$ oadm create-login-template > login-template.html
$ oadm create-provider-selection-template > provider-selection-template.html

Edit the file to change the styles or add content, but be careful not to remove any required parameters inside the curly brackets.

To use your custom login page or provider selection page, set the following options in the master configuration file:

oauthConfig:
  ...
  templates:
    login: /path/to/login-template.html
    providerSelection: /path/to/provider-selection-template.html

Relative paths are resolved relative to the master configuration file. You must restart the server after changing this configuration.

When there are multiple login providers configured or when the alwaysShowProviderSelection option in the master-config.yaml file is set to true, each time a user’s token to OpenShift Enterprise expires, the user is presented with this custom page before they can proceed with other tasks.

Example Usage

Custom login pages can be used to create Terms of Service information. They can also be helpful if you use a third-party login provider, like GitHub or Google, to show users a branded page that they trust and expect before being redirected to the authentication provider.

Customizing the OAuth Error Page

When errors occur during authentication, you can change the page shown.

  1. Run the following command to create a template you can modify:

    $ oadm create-error-template > error-template.html
  2. Edit the file to change the styles or add content.

    You can use the Error and ErrorCode variables in the template. To use your custom error page, set the following option in the master configuration file:

    oauthConfig:
      ...
      templates:
        error: /path/to/error-template.html

    Relative paths are resolved relative to the master configuration file.

  3. You must restart the server after changing this configuration.

Changing the Logout URL

You can change the location a console user is sent to when logging out of the console by modifying the logoutURL parameter in the /etc/origin/master/master-config.yaml file:

...
assetConfig:
  logoutURL: "http://www.example.com"
...

This can be useful when authenticating with Request Header and OAuth or OpenID identity providers, which require visiting an external URL to destroy single sign-on sessions.

Configuring Web Console Customizations with Ansible

During advanced installations, many modifications to the web console can be configured using the following parameters, which are configurable in the inventory file:

Example 1. Example Web Console Customization with Ansible
# Configure logoutURL in the master config for console customization
# See: https://docs.openshift.com/enterprise/latest/install_config/web_console_customization.html#changing-the-logout-url
#openshift_master_logout_url=http://example.com

# Configure extensionScripts in the master config for console customization
# See: https://docs.openshift.com/enterprise/latest/install_config/web_console_customization.html#loading-custom-scripts-and-stylesheets
#openshift_master_extension_scripts=['/path/on/host/to/script1.js','/path/on/host/to/script2.js']

# Configure extensionStylesheets in the master config for console customization
# See: https://docs.openshift.com/enterprise/latest/install_config/web_console_customization.html#loading-custom-scripts-and-stylesheets
#openshift_master_extension_stylesheets=['/path/on/host/to/stylesheet1.css','/path/on/host/to/stylesheet2.css']

# Configure extensions in the master config for console customization
# See: https://docs.openshift.com/enterprise/latest/install_config/web_console_customization.html#serving-static-files
#openshift_master_extensions=[{'name': 'images', 'sourceDirectory': '/path/to/my_images'}]

# Configure extensions in the master config for console customization
# See: https://docs.openshift.com/enterprise/latest/install_config/web_console_customization.html#serving-static-files
#openshift_master_oauth_template=/path/on/host/to/login-template.html

# Configure metricsPublicURL in the master config for cluster metrics. Ansible is also able to configure metrics for you.
# See: https://docs.openshift.com/enterprise/latest/install_config/cluster_metrics.html
#openshift_master_metrics_public_url=https://hawkular-metrics.example.com/hawkular/metrics

# Configure loggingPublicURL in the master config for aggregate logging. Ansible is also able to install logging for you.
# See: https://docs.openshift.com/enterprise/latest/install_config/aggregate_logging.html
#openshift_master_logging_public_url=https://kibana.example.com