Environment variables

Before modify

If you 146% sure that project requires another one env var Contact DevOps dpt first. And after applying changes, patch this document.

This document affects the whitelabel aka core aka cloud project. But the widgets and fe-be could follow this spec.

Overview

All of these values are required for the start of the application.

We have two ways to handle this:

• Production;
• Dev;
• fe-be.

Runtime Mandatory Variables

Main runtime variables for the whitelabel project could be found in wlabel/src/templates/index.html.

Value Name	Description	Editable	Default value	Validation principle	Required
OIDC_CLIENT_ID	Client ID in IDP	Yes	Empty	UUID	Yes
OIDC_BASE_URL	Core IDP adresses	Yes	Empty	URL	Yes
OIDC_REDIRECT_URL	The URL where users are redirected after login	Yes	Empty	URL/localhost	Yes
OIDC_AUTH_ENDPOINT	The endpoint where requests are sent after token renewal	Yes	Empty	URL	Yes
OIDC_END_SESSION_ENDPOINT	The endpoint where requests are sent for session timeout	Yes	Empty	URL/URL path	Yes
OIDC_PARAMETERS	Configuration which is added to requests on IDP	Yes	Empty	JSON	Yes
API_BASE_URL	The base URL for API calls. For example, we have endpoint GET: /users and API_BASE_URL=https://my-owsome.host.com then this endpoint will be transformed to https://my-owsome.host.com/users	Yes	Empty	URL	Yes
CUSTOM_ENV	Project-specific parameters that shouldn't be shared with others	Yes	Empty	JSON	No
CUSTOMIZATION_BE	Like the API_BASE_URL but points to the BfF server	Yes	Empty	URL	Yes
STORE_BASE_URL	The link to storage of static bundles. All the widgets' executable code will be pulled from there	Yes	Set by us	URL	Yes
WIDGET_STORE_API_URL	The URL of the widget store API	Yes	Set by us	URL	Yes
SHOW_WIDGET_PREVIEW	The "flag" parameter which shows if widget miniatures should be displayed or not	Yes	Set by us	boolean	Yes

Production way

Motivation

As far as we are using Docker and Kubernetes we have to stay with the strategy: many deploy envs & single docker containers.

How it works

All vars mentioned in 1.1 are declared inside the <script/> tag of the index.html template. So all these things will be replaced with simple sed + awk (bash script) due to deploy pipeline. Values will be taken from $ENV of the docker container.

Dev way

Motivation

As far as we developing these things for the number of vendors and several specific API versions (dev/staging/uat/beta/e.t.c.) we have to keep the ability to switch values of these vars in compile time due to the dev process.

How it works

In dev-mode, we use the devIndex.html template free from declarations listed in 1.1. All the vars will be passed via DefinePlugin.

All exposed variables could be found in wlabel/webpack/build-vars.js. Also to keep the ability of flexible value change on the root level of wlabel you can find the devmode-vars.example.json file.

Each time you will start build_federation or maybe another local dev script webpack will try to access devmode-vars.json. The devmode-vars.json file is listed in .gitignore so YOU HAVE TO CREATE THIS FILE MANUALLY.

Currently known secrets (devmode-vars.json)

Currently, known secrets could be found in secrets-repo

fe-be

Motivation

Customization backend uses API_URL env variable.

How it works

For locals, it is better to run something like $ export API_URL=https://current-api-url:port.

In production, this var will be consumed from $ENV.

Also for the OAuth and route protection things, there is a special config file in the root of a project env-vars.json

{
  "jwksUri": "https://login.microsoftonline.com/common/discovery/keys",
  "authIssuer": "https://sts.windows.net/*uuid*/",
  "whiteListEndpoints": [
    "/images",
    "/fonts",
    "/theme",
    "/theme/*vendor-default-theme*"
  ],
  "PORT": 1337
}

• whiteListEndpoints contains a specific theme. This could be required in case you want to cover your login page with theme parameters before the actual auth process.