Helix Core is now P4 and Helix Swarm is now P4 Code Review. Learn more >>

Documentation | 2025.2

# Security

There are many strategies for securing a P4 Code Review installation. This section provides guidance on security features P4 Code Review controls, and recommendations for several areas for the system hosting P4 Code Review.

If you make a configuration change, P4 Code Review will not use it until the configuration cache has been reloaded, this forces P4 Code Review to use the new configuration. You must be an admin or super user to reload the P4 Code Review config cache. Navigate to the User id dropdown menu, select System Information, click the Cache Info tab, and click the Reload Configuration button.

## Require login

Prior to P4 Code Review's 2016.1 release, `require_login` defaulted to `false`. For 2016.1 and later releases, the default is `true`.

By default, P4 Code Review prevents anonymous users from viewing any P4 Server resources; users must login to see commits, reviews, etc.

P4 Code Review can be configured to allow anonymous users to access any readable resources (creating or editing resources by anonymous users is not permitted). Add the following configuration block to the `SWARM_ROOT/data/config.php` file, at the same level as the p4 entry:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'require_login' => false, // defaults to true
        ),

There is one exception: the `/queue/worker` endpoint is available to any user.

Service and operator users are not permitted to login. For more information on these user types, see Types of users in P4 Server Administration Documentation.

## Prevent login

When your P4 Server has users that should not be able to log in to P4 Code Review, for example service users involved with P4 Server replicas, the `prevent_login` configuration item can be used to prevent successful authentication.

Add or update the following configuration block to the `SWARM_ROOT/data/config.php` file, at the same level as the p4 entry:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'prevent_login' => array(
                'service_user1',
                'service_user2',
            ),
        ),

prevent_login defaults to `array()`, which means no users in your P4 Server are prevented from logging into P4 Code Review.

For more information, see Service users in P4 Server Administration Documentation.

## Auto-create new users

P4 Code Review supports the automatic-creation of new users in Perforce on login if the P4 Server is configured to allow it and the user exists in LDAP. This function is configured in the P4 Server and no P4 Code Review configuration is required. For instructions on how to configure P4 Server to automatically create new users in Perforce on login, see auth.ldap.userautocreate and auth.default.method in the Defining LDAP-related configurables section of the P4 Server Administration Documentation.

To enable the auto-creation of users in P4 Code Review, you must set the auto_create_user configurable to true in the `SWARM_ROOT/data/config.php` file, which is located under the security section. By default, this setting is not defined, which means that user auto-creation is not enabled. The same applies if it is explicitly set to false.

The auto-creation of users also works with non-LDAP users. When user auto-creation is enabled and a non-LDAP user, who does not yet exist in the P4 Server logs in for the first time on the P4 Code Review login page and provides their password, they will see an error message. However, despite this error message, the user will be created in the P4 Server with a blank password. In this case, the user will need to reset their password using the P4 Command-line interface (CLI) or P4 Visual Client (P4V) for security reasons.

## Sessions

P4 Code Review manages logged-in sessions using cookies in the browser, and PHP session storage on the server. P4 Code Review uses reasonable defaults for the cookie and session lifetimes (measured in seconds); when the lifetime is exceeded users need to login again. To specify session lifetimes and garbage collection frequency, add the following configuration block to the `SWARM_ROOT/data/config.php` file, at the same level as the `p4` entry:

    <?php
        // this block should be a peer of 'p4'
        'session' => array(
            'cookie_lifetime'            => 0, // lifetime in seconds, default value is 0=expire when browser closed
            'remembered_cookie_lifetime' => 60*60*24*30,  // lifetime in seconds, default value is 30 days
            'cookie_samesite'            => 'lax' //SameSite attribute to prevent the web browser from sending the cookie in cross-site requests
                                                  //default is 'lax' 'strict'|'lax'|'none'
            'user_login_status_cache'    => 10, // Set in seconds, default value is 10 seconds.
                                                // Set to 0 to disable the cache and make P4 Code Review
                                                // check the user login status for every call to Helix Server.
            'gc_maxlifetime'             => 60*60*24*30, // lifetime in seconds, default value is 30 days
            'gc_divisor'                 => 100, // 100 user requests
        ),

- cookie_lifetime

  Optional: Limits the lifetime of session cookies (in seconds).

  Default is `0`, which causes the session cookie to expire when the user's browser is closed.

  Maximum value is 2147483647 seconds.

  When the Remember Me checkbox on the login dialog is checked, the `remembered_cookie_lifetime` value will be used for `cookie_lifetime`.

- remembered_cookie_lifetime

  Optional: Limits the lifetime of session cookies when the Remember Me checkbox on the login dialog is checked.

  Default is `60*60*24*30` seconds (30 days). You can enter the value in seconds if you prefer. For example, 2592000 seconds (30 days) is also valid.

  Maximum value is 2147483647 seconds.

- cookie_samesite

  Optional: Prevents the web browser from sending cookies in cross-site requests. This can help prevent cross-site request forgery (CSRF) attacks.

  - lax: The cookie is not sent on cross-site sub-requests, such as calls to load images or frames, but is sent when a user navigates to the URL from an external site, such as by following a link. This is the default.

  - strict: The web browser will only send the cookie for same-site requests, which means requests that come from the same site that initially set the cookie. If a request comes from a different domain or scheme (even if it's the same domain), no cookies with the attribute cookie_samesite set to strict will be sent.

  - none: This can only be used if you are using HTTPS and the cookie is also marked secure; setting cookie_samesite to none without the secure flag may lead to the cookie being rejected.

- user_login_status_cache

  P4 Code Review 2022.1 and later: P4 Code Review caches the P4 Server login status of users. When P4 Code Review makes any single request, it tests the user's login status many times. The default 10 second cache value is intended to reduce the number of checks performed, reducing the load on the P4 Server.

  Default is `10` seconds.

  Set to 0 to disable the cache and make P4 Code Review check the login status for every call to the P4 Server.

  If a user requests a P4 Code Review operation on the P4 Server when logged out of the P4 Server, but their login cache status shows them as logged in, the operation will fail. If you get too many reports of failed operations, reduce your cache setting.

- gc_maxlifetime

  Optional: If a session is inactive for the specified number of seconds, the user is logged out. User sessions are stored in `SWARM_ROOT/data/sessions/`.

  Default is `60*60*24*30` seconds (30 days). You can enter the value in seconds if you prefer. For example, 2592000 seconds (30 days) is also valid.

  Maximum value is 2147483647 seconds.

  By default, the user's Perforce ticket expires after 12 hours, which also causes them to be logged out.

- gc_divisor

  Optional: Sets how often garbage collection is run based on the number of user requests that are made. The setting range is 1 to 100. Garbage collection deletes user session files that are older than the `gc_maxlifetime` setting from `SWARM_ROOT/data/sessions/`.

  - gc_divisor = 100: Garbage collection runs after every 100th user request. 100 is the default setting.
  - gc_divisor = 1: Garbage collection runs after every user request.

  If your P4 Code Review system has a large number of users, setting `gc_divisor` to a low number can result in performance issues.

## Security headers

P4 Code Review uses the following security headers to enhance its security:

- X-Frame-Options

- X-XSS-Protection

- X-Content-Type-Options

- Referrer-Policy

- Strict-Transport-Security (HSTS)

- Subresource Integrity (SRI)

- Content-Security-Policy

- Permissions-Policy

- X-Forwarded-For

For more information on the security headers, see this Mozilla Developer Network article.

### X-Frame-Options

By default, P4 Code Review emits a `X-Frame-Options` HTTP header set to `SAMEORIGIN`. This prevents embedding of the P4 Code Review interface into other web pages, which avoids click-jacking attacks.

If your deployment of P4 Code Review needs to be integrated into another web interface, you can adjust the `X-Frame-Options` header by adjusting the `x_frame_options` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'x_frame_options' => value,
            ),
        ),

Where value can be one of:

- 'SAMEORIGIN' - P4 Code Review can only be displayed in a frame hosted on the same domain.

- 'DENY' - P4 Code Review cannot be displayed in a frame.

- 'ALLOW-FROM URI' - P4 Code Review can only be displayed in a frame hosted on the specified URI.

- false - The `X-Frame-Options` header is not emitted, so P4 Code Review can be embedded without restriction.

For more information on click-jacking attacks, see this Wikipedia article.

### X-XSS-Protection

By default, P4 Code Review emits a X-XSS-Protection HTTP header set to 1; mode=block. This stops P4 Code Review from loading when it detects reflected cross-site scripting (XSS) attacks.

If your deployment of P4 Code Review does not want to stop loading when P4 Code Review detects reflected cross-site scripting (XSS) attacks, you can adjust the X-XSS-Protection header by adjusting the `x_xss_protection` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'x_xss_protection' => '1',
            ),
        ),

For more information on X-XSS-Protection HTTP header, see Mozilla X-XSS-Protection.

### X-Content-Type-Options

By default, P4 Code Review emits a X-Content-Type-Options HTTP header set to nosniff. This header blocks a web browsers' MIME type sniffing, which can transform non-executable MIME types into executable MIME types (MIME Confusion Attacks).

If your deployment of P4 Code Review does not want to emit a X-Content-Type-Options HTTP header, you can adjust the X-Content-Type-Options header by adjusting the `referrer_policy` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'x_content_type_options' => 'nosniff',
            ),
        ),

### Referrer-Policy

By default, P4 Code Review emits a Referrer-Policy HTTP header set to strict-origin-when-cross-origin. This prevents P4 Code Review from sending all the referrer information (origin, path, and query string) to the same site but only sends the origin to other sites.

If your deployment of P4 Code Review needs to send all the referrer information (origin, path, and query string) to the same site, you can adjust the Referrer-Policy header by adjusting the `referrer_policy` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'referrer_policy' => 'value',
            ),
        ),

Where value can be one of:

- 'no-referrer' - No referrer information is sent.

- 'no-referrer-when-downgrade' - Referrer is sent to the same protocol or more secure.

- 'same-origin' - Referrer is sent only for same-origin requests.

- 'origin' - Only the origin (scheme, host, and port) is sent as the referrer.

- 'strict-origin' - Only the origin is sent, but only for HTTPS requests.

- 'origin-when-cross-origin' - Full URL for same-origin requests is sent and origin only for cross-origin requests.

- 'strict-origin-when-cross-origin' - Full URL for same-origin requests, origin only for cross-origin requests if downgraded. This is the default value.

- 'unsafe-url' - Full URL is sent with all requests.

### Strict-Transport-Security (HSTS)

By default, P4 Code Review uses a Strict-Transport-Security response header set to max-age=15724800. This ensures that P4 Code Review is only accessed using HTTPS, instead of HTTP.

If your deployment of P4 Code Review needs to use HTTP, you can adjust the Strict-Transport-Security response header by adjusting the `strict_transport_security_policy` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'strict_transport_security_policy' => 'max-age=15724800',
            ),
        ),

Where value can be one of:

- 'max-age=<expire-time>' - Specifies the time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.

- 'includeSubDomains': Optional; applies the rule to all subdomains.

- 'preload': Optional; signals the web browser to include the domain in its preload list for HSTS.

For more information on Strict-Transport-Security (HSTS) response header, see HTTP Strict Transport Security Cheat Sheet.

### Subresource Integrity (SRI)

By default, P4 Code Review uses Subresource-Integrity header to enable browsers to verify that resources they fetch (like scripts or stylesheets) are delivered without unexpected manipulation. The value of the integrity attribute is a hash of the resource's contents.

You can adjust the Subresource-Integrity header by adjusting the `subresource_integrity` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'subresource_integrity' => 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9Gh0ad+vyT/qVYY5PbJ5r61tP34jA4kFJgNH4=',
            ),
        ),

The possible hash functions include:

- sha256-<base64-value>

- sha384-<base64-value>

- sha512-<base64-value>

The crossorigin attribute is often used with SRI to ensure the correct handling of Cross-Origin Resource Sharing (CORS). Example usage in HTML:

    <link rel="stylesheet" href="https://example.com/style.css" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9Gh0ad+vyT/qVYY5PbJ5r61tP34jA4kFJgNH4=" crossorigin="anonymous">

### Content-Security-Policy

By default, P4 Code Review uses the Content-Security-Policy header set to default-src 'unsafe-eval' 'unsafe-inline' 'self' data: blob: *;. This helps to prevent a variety of attacks such as Cross-Site Scripting (XSS) and other code injection attacks.

You can adjust the Content-Security-Policy header by adjusting the `content_security_policy` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'content_security_policy' => "default-src 'unsafe-eval' 'unsafe-inline' 'self' data: blob: *;",
            ),
        ),

The possible values are a combination of directives and their sources. Some common directives include:

- 'default-src' - Specifies the default source for all content types.

- 'script-src' - Defines valid sources for JavaScript.

- 'style-src' - Defines valid sources for stylesheets.

- 'img-src' - Defines valid sources for images.

- 'connect-src' - Defines valid sources for fetching via XMLHttpRequest, WebSockets, etc.

- 'font-src' - Defines valid sources for fonts.

- 'object-src' - Defines valid sources for plugins like Flash.

- 'media-src' - Defines valid sources for media files like audio or video.

- 'frame-src' - Defines valid sources for nested browsing contexts (like iframes).

- 'report-uri' - Specifies the URI where reports of policy violations are sent.

- 'frame-ancestors' - Specifies valid parents that may embed a page using `frame`, `iframe`, or `object`.

### Permissions-Policy

By default, P4 Code Review uses the Permissions-Policy header to control which origins can use which browser features, both in the top-level page and in embedded frames. For every feature controlled by the Permissions-Policy header, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins. This means that you can configure your site to never allow the camera or microphone to be activated. This prevents an injection, such as XSS, which could enable the camera, the microphone, or other browser features.

You can adjust the Permissions-Policy header by adjusting the `permissions_policy` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'permissions_policy' => 'geolocation=(), camera=(), microphone=()',
            ),
        ),

### X-Forwarded-For

P4 Code Review uses the X-Forwarded-For request header to identify the originating IP address of a client running a load balancer or proxy server in front of P4 Code Review. By default, X-Forwarded-For request header forwarded_address is set to false.

You can use the X-Forwarded-For request header by adjusting the `forwarded_address` item within the security configuration block, found in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'forwarded_address' => false,
            ),
        ),

#### Recommendations for implementation through security groups

Here is a list of best practices for implementation using security groups or the user's preferred setup:

- Use a trusted proxy: Ensure to only use a trusted proxy, such as allow lists, Content Delivery Networks (CDN), and API Gateways.

- Backend servers and other proxies or load balancers should be disabled: Ensure that direct access to backend servers and other proxies or load balancers is disabled, except through the trusted proxy mentioned above. This will prevent unauthorized access while ensuring that all requests are filtered through the trusted proxy.

- Continuous monitoring and logging of the X-Forwarded-For header: Implement monitoring and logging on the X-Forwarded-For header to track and identify any suspicious activities. This can help in identifying and preventing potential malicious activity or security threats.

- Use a secure protocol: Implement a secure protocol such as HTTPS to encrypt the communications between the client and the load balancers, and between the load balancer and backend server to prevent eavesdropping or tampering with the X-Forwarded-For header.

- Configure X-Forwarded-For header: Configure the processing mode of the X-Forwarded-For header (append, preserve, or remove) based on specific technical or security requirements.

## Disable commit

P4 Code Review provides the ability to commit reviews within the P4 Code Review interface. You may want to disable this capability to prevent reviews from being committed by someone other than the review's author. When disabled, the Approve and Commit (and Commit if the review is already approved) option is removed from the list of states available to a code review.

To disable commits, set `disable_commit` to `true` within the reviews item in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'reviews' => array(
            'disable_commit' => true,
            ),
        ),

## Restricted Changes

The P4 Server provides two changelist types: `public` (the default), and `restricted`. P4 Code Review honors restricted changelists by preventing access to the changelist, and any associated comments or activity related to the changelist.

If a user has list-level privileges to at least one file in the changelist, P4 Code Review allows the user to see the changelist and any of the files they have permission to see.

To prevent unintended disclosures, email notifications for restricted changes are disabled by default. To enable email notifications for restricted changes, set `email_restricted_changes` to `true` within the security item in the `SWARM_ROOT/data/config.php` file. For example:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'email_restricted_changes' => true,
            ),
        ),

When `email_restricted_changes` is set to `true`, email notifications for restricted changes are sent to all interested parties with no permissions screening. These notifications might disclose sensitive information.

P4 Code Review can only report on changes that the configured admin-level user has access to. When using restricted changes, we advise that you grant the P4 Code Review admin-level user access to the restricted files and set `require_login = true` to avoid leaking information to unauthenticated users.

## Limit adding projects to administrators

For P4 Code Review 2016.1, the configuration item `add_project_admin_only` was moved from the `security` block to the ``projects` block`, and the item was renamed to `add_admin_only`. The functionality of this configuration item remains unchanged.

If you do not update your `SWARM_ROOT/data/config.php` configuration file, the old configuration for restricting project creation to administrators continues to work.

If you add the new configuration item `add_admin_only` to the `projects` block, it takes precedence over any remaining `add_project_admin_only` setting in the `security` block.

## Limit adding projects to members of specific groups

For P4 Code Review 2016.1, the configuration item `add_project_groups` was moved from the `security` block to the ``projects` block`, and the item was renamed to `add_groups_only`. The functionality of this configuration item remains unchanged.

If you do not update your `SWARM_ROOT/data/config.php` configuration file, the old configuration for restricting project creation to specific groups continues to work.

If you add the new configuration item `add_groups_only` to the `projects` block, it takes precedence over any remaining `add_project_groups` setting in the `security` block.

## IP address-based protections emulation

A P4 Server can be configured via protections to restrict access to a depot in a variety of ways, including by IP address. As P4 Code Review is a web application acting as a client to the P4 Server, often with admin-level privileges, P4 Code Review needs to emulate IP address-based restrictions. It does so by checking the user's IP address and applying any necessary restrictions during operations such as browsing files, viewing file content, viewing and adding comments on files.

P4 Code Review also emulates proxy-based protections, in addition to regular IP-based protections emulation. However, P4 Code Review does not detect whether it is connecting to a P4 Proxy or not; it merely attempts to emulate protections table entries that use proxy syntax.

IP address-based protections emulation is disabled by default. To enable IP address-based protections emulation for your P4 Code Review installation, include the following configuration item in the `SWARM_ROOT/data/config.php` file:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'emulate_ip_protections' => true,
        ),

If P4 Code Review is connected to multiple P4 Server instances, you have the following options for emulate_ip_protections:

- To apply a global emulate_ip_protections setting to all P4 Server instances that P4 Code Review is connected to, set emulate_ip_protections in the security block as shown above.
- To apply an individual emulate_ip_protections setting to a P4 Server instance, set emulate_ip_protections in the serverid block for that server. This value overrides the global setting in the security block for the P4 Server instance.

For more information about configuring P4 Code Review for multiple P4 Server instances, see Set up the P4 Code Review configuration file for the P4 Servers.

### Known limitations

- Notification e-mails for reviews or commits include the list of affected files. P4 Code Review cannot reliably know the IP address used to retrieve that e-mail, and makes no attempt to filter the files and their depot paths nor any details included in the description. However, when a user follows a link from the notification e-mail to a restricted resource, that access is denied.
- P4 Code Review filters comments from activity streams, but any comments created prior to upgrading to the 2013.3 release cannot be filtered and may leak sensitive information.
- P4 Code Review displays a comment count in code the review list, code reviews, jobs, and activity streams, but the count does not account for any comments that may be hidden from the user due to association with files the user is restricted from viewing.
- Should P4 Code Review users connect to P4 Code Review via a proxy or VPN, the protections will generally use the IP address of the proxy/VPN.
- When the user's IP address and P4 Code Review's IP address both have restrictions applied, the user experiences the most constraining of the two IP address-based restrictions; P4 Code Review cannot bypass restrictions applied to itself.
- P4 Code Review performs a variety of operations with admin-level privileges, on behalf of a user. Even if the P4 Server has IP-based, or userid-based protections, installed to prevent access to some or most of its versioned data, P4 Code Review typically does have access to this data. Therefore, P4 Code Review cannot guarantee that no information leakage will occur, particularly when custom modules are in use, or P4 Code Review source has been customized.

For more information, see Access authorization in P4 Server Administration Documentation.

## Disable system info

P4 Code Review provides a System Information page, available to users with admin or super privileges, which displays information about P4 Server that P4 Code Review is configured to use, as well as PHP information and the P4 Code Review log file.

While this information can be invaluable when communicating with Perforce support engineers, you may wish to prevent disclosure of any system information. The System Information page can be disabled for all users by adding the following configuration block to the `SWARM_ROOT/data/config.php` file, at the same level as the p4 entry:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'disable_system_info' => true, // defaults to false
        ),

Once disabled, the System Information link disappears from the About P4 Code Review dialog, and 403 errors are generated for any attempts to browse to the System Information page.

## HTTP client options

P4 Code Review permits configuration of options that are passed through to the underlying Laminas Framework HTTP client. These options can be used to specify SSL certificate locations, request timeouts, and more, and can be specified globally or per host. To use the P4 Code Review Slack integration through a proxy server, see Use Slack integration through a proxy server.

Here is an example configuration:

    <?php
        // this block should be a peer of 'p4'
        'http_client_options' => array(
            'timeout'       => 10, // default value is 10 seconds

            // path to the SSL certificate directory
            'sslcapath'     => '',

            // the path to a PEM-encoded SSL certificate
            'sslcert'       => '',

            // the path to Certificate Authority file
            'sslcafile'       => '',

            // the passphrase for the SSL certificate file
            'sslpassphrase' => '',

            // optional, per-host overrides;
            // host as key, array of options as value
            'hosts'     => array(
                'jira.example.com'  => array(
                    'sslcafile'     => '/path/to/certs/jira.pem',
                    'sslpassphrase' => 'keep my JIRA secure',
                    'timeout'       => 15,
                ),
                'jenkins.example.com' => array(
                    'sslcafile'       => '/path/to/certs/jenkins.pem',
                    'sslpassphrase'   => 'keep my jenkins very secure',
                    'timeout'         => 15,
                ),
                'slack.com'  => array(
                    'adapter'    => 'Laminas\Http\Client\Adapter\Proxy',
                    'proxy_host' => 'squidproxy',
                    'proxy_port' => '3128',
                ),
            ),
        ),

See the Laminas Framework Socket Adapter documentation for more information.

P4 Code Review supports the Laminas component versions in the LICENSE.txt file, features and functions in the Laminas documentation that were introduced in later versions of Laminas will not work with P4 Code Review. The LICENSE.txt file is in the readme folder of your P4 Code Review installation.

While it is possible to use a self-signed SSL certificate, adding the configuration to do so disables certificate validity checks, making connections to the configured host less secure. We strongly recommend against using this configuration option. For more information about the risks of using a self-signed SSL certificate, see Security risks of using a self-signed certificate.

However, if you need to configure continuous integration, deployment, or JIRA connections and those connections must use a self-signed SSL certificate, set the `sslallowselfsigned` item to `true` for the specific host that needs it, as in the following example:

    <?php
        // this block should be a peer of 'p4'
        'http_client_options' => array(
            'hosts'     => array(
                'jira.example.com'  => array(
                    'sslallowselfsigned'  => true,
                ),
            ),
        ),

## Strict HTTPS

To improve the security when users work with P4 Code Review, particularly if they need to do so outside of your network, P4 Code Review provides a mechanism that tries to force web browsers to use HTTPS. When enabled, P4 Code Review's behavior changes in the following ways:

- HTTP requests to P4 Code Review include a meta-refresh to the HTTPS version. If a load balancer handles encryption before requests reach P4 Code Review, the meta-refresh should be disabled. See below.
- A strict transport security header is included for all requests, which pins the browser to using HTTPS for your P4 Code Review installation for 30 days.
- All qualified URLs that P4 Code Review produces use HTTPS for the scheme.
- Cookies are flagged as HTTPS-only.

Here is an example of how to enable strict HTTPS:

    <?php
        // this block should be a peer of 'p4'
        'security' => array(
            'https_strict'          => true,
            'https_strict_redirect' => true, // optional; set false to avoid meta-refresh
            'https_port'            => null, // optional; specify if HTTPS is
                                             // configured on a non-standard port
        ),

When the `https_strict_redirect` item is set to `false`, P4 Code Review does not add a meta-refresh for HTTP clients. This prevents an endless redirect when a load balancer in front of P4 Code Review applies HTTPS to the client-to-load balancer connection, but not the load balancer-to-P4 Code Review connection.

## Apache security

There are several Apache configuration changes that can improve security for P4 Code Review:

- Disable identification

  By default, each Apache response to a web request includes a list of tokens identifying Apache and its version, along with any installed modules and their versions. Also, Apache can add a signature line to each response it generates that includes similar information. By itself, this identification information is not a security risk, but it helps would-be attackers select attacks that could be successful.

  To disable Apache identification, add the following two lines to your Apache configuration:

      ServerSignature Off
      ServerTokens ProductOnly

- Disable TRACE requests

  TRACE requests cause Apache to respond with all of the information it has received, which is useful in a debugging environment. `TRACE` can be tricked into divulging cookie information, which could compromise the credentials being used to login to P4 Code Review.

  To disable `TRACE` requests, add the following line to your Apache configuration:

      TraceEnable off

- Update SSL configuration

  P4 Code Review works correctly with an SSL-enabled Apache. Several attacks on common SSL configurations have been published recently. We recommend that you update your Apache configuration with the following lines:

      <IfModule mod_ssl.c>
          SSLHonorCipherOrder On
          SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
          SSLCompression Off
      </IfModule>

## PHP security

There are several PHP configuration changes that can improve security for P4 Code Review:

- Disable identification

  By default, PHP provides information to Apache that identifies that it is participating in a web request, including its version.

  To disable PHP identification, edit your system's php.ini file and change the line setting `expose_php` to:

      expose_php = Off

- Remove scripts containing phpinfo()

  During module development or other debugging, you may need to call `phpinfo()`, which displays PHP's active configuration, compilation details, included modules and their configuration. Typically, you would add a script to P4 Code Review's public directory containing:

      <?php phpinfo() ?>

  Any such scripts should be removed from a production instance of P4 Code Review.

## proxy_mode

By default, P4 Code Review works in proxy mode, passing the end-user's browser IP address to the P4 Server. The P4 Server checks the IP address against its IP protection table to work out what permissions the end-user has.

Set the P4 Code Review proxy_mode in the p4 configuration block of the `SWARM_ROOT/data/config.php` file:

    <?php
        'p4' => array(
            'proxy_mode' => true, // defaults to true
        ),

- true: P4 Code Review passes the end-user's browser IP address to the P4 Server allowing the P4 Server to work out the what permissions the end-user has. This is the default setting.
- false: the P4 Code Review server IP address is passed to the P4 Server. The P4 Server checks the P4 Code Review IP address against its protections table to work out the permissions the end-user has. The result is that all of the P4 Code Review users will have the same permissions.

If P4 Code Review is connected to multiple P4 Server instances, you have the following options for proxy_mode:

- To apply a global proxy_mode setting to all P4 Server instances that P4 Code Review is connected to, set proxy_mode in the p4 block as shown above.
- To apply an individual proxy_mode setting to a P4 Server instance, set proxy_mode in the serverid block for that server. This value overrides the global setting in the p4 block for the P4 Server instance.

For more information about configuring P4 Code Review for multiple P4 Server instances, see Set up the P4 Code Review configuration file for the P4 Servers.

Your search for returned results