Enabling Developer Portal feature flags on OpenShift and Cloud Pak for Integration

Use a template override to update the installation CR with settings that control the default behavior of the Developer Portal subsystem.

About this task

You can add a template override to the Developer Portal subsystem CR to change the default behavior of the Portal subsystem, or to turn specific features on and off. Table 1 describes the available feature flags.

Table 1. List of available feature flags for the Developer Portal
Feature flag name	Default Value	Pod	Container	Description
`PORTAL_SKIP_WEB_ENDPOINT_VALIDATION`	`true`	`www`	`admin`	Controls whether the Portal subsystem checks whether the Portal web endpoint is accessible. Sometimes, the endpoint cannot be reached, for example due to the complexity of the networks. In which case the following type of error can be seen in the `portal-www` pod, and `admin` container logs: `An error occurred contacting the provided portal web endpoint: example.com The provided Portal web endpoint example.com returned HTTP status code 504` You can disable the check by setting this flag to `false`.
`ENABLE_TRUSTED_REVERSE_PROXY`	`false`	`www`	`admin`	Controls whether the Drupal `trusted_reverse_proxy` module can manage the reverse proxies list. If you have multiple load balancers and reverse proxies in your upstream network, and the perimeter module is triggered, the incorrect IP address might be banned rather than the intended client IP address. However, you can manage which IP addresses are banned by using the Drupal `trusted_reverse_proxy` module, and setting this feature flag to `true`. The Drupal module inspects the `x-forwarded-for` headers to identify the reverse proxies, and trusts that the first IP address found in the list is the client IP. For example, in `X-Forwarded-For: <client>, <proxy1>, <proxy2>`, the client IP `<client>` will be banned. For more information about this module, see https://www.drupal.org/project/trusted_reverse_proxy. To use this module, you must ensure that all of the proxies in your upstream network, including the ingress controller, are configured correctly so that the `x-forwarded-for` header is passed through to the `portal-www` pod. For example, the default behavior of the `nginx-ingress-controller` is to ignore the inbound `x-forwarded-for` header, and create a new one. To change this behavior, update the `nginx-ingress-controller` `configmap` with the following information: `data: compute-full-forwarded-for: "true" use-forwarded-headers: "true"` Warning: Enable this feature flag only if you trust your upstream reverse proxies, as it is possible to trick the `x-forwarded-for` header.

Procedure

If API Connect is already deployed, retrieve the name of the deployed CR by running the following command:
```
oc get apiconnectcluster -n <APIC_namespace>
```
If API Connect yet is not yet deployed, skip this step.

Edit the apiconnectcluster CR by running the following command:

oc edit apiconnectcluster <APIC_instance_name> -n <APIC_namespace>

In the CR, append the feature flag definition to the end of the spec.portal section, making sure to adhere to the spacing used in the file.

You can add multiple feature flags as follows:

spec:
  template
  - containers:
      - env:
          - name: PORTAL_SKIP_WEB_ENDPOINT_VALIDATION
            value: 'true'
        name: admin
    name: ptl-www

spec:
  template
  - containers:
      - env:
          - name: ENABLE_TRUSTED_REVERSE_PROXY
            value: 'true'
        name: admin
    name: ptl-www

Close and save the file with the following command:
```
:wq
```
The Developer Portal subsystem is updated to enable or disable features as specified.