You may supply any HTML content to display to clients in case of errors, these error pages will override the default X4B Pages. These error pages will not however override any error pages served from your web server which will not be touched by our services

Error Page defaults

All error codes (and mitigation pages) available for user override have default error pages provided by us. These error pages provided by us are available in multiple languages. Language contributions are largely provided by customers, if you wish to contribute a translation please contact us.

Default Error Pages (served by us) can be identified by a comment of <!-- X4B --> before the final HTML tag. Unless the error page relates to a billing matter (such as non-payment) we do not include visible branding in these pages. You can view HTML comments from the "View Source" page of your web browser or with software that displays HTML as text output (such as curl).

Error Page override

All HTTP Error Pages can be overridden by customers at the (virtual) port level.

The available error pages include:

  • HTTP 403: Forbidden due to ACL
  • HTTP 408: Client Timeout
  • HTTP 481: Insecure Request
  • HTTP 497: An HTTP request sent to an HTTPS port
  • HTTP 500: Internal Service Error
  • HTTP 502: Bad Backend
  • HTTP 503: Service Unavailable
  • HTTP 504: Backend Timeout
  • HTTP 521: Too Many Connections (HTTP 503)
  • HTTP 522: Request Limited (HTTP 503)

Redirection URL

Optionally a redirection URL may also be supplied. Redirection URLs may also include the following variables:

  • $scheme - Either http or https depending on the clients connection
  • $host - The connecting hostname
  • $uri - The request path component including the starting "/"

  • $request_uri - The request path component including the starting "/"

    Redirection URLs allow for redirection on error. Redirects may be either Temporary or Permanent and may optionally also forward POST data.

    On Error code "481: Insecure Request" this may be used to redirect HTTP (insecure) traffic received on an HTTPS port which can be useful for certain applications.

Maintenance

Configure maintenance mode in Access Control → Maintenance. You may supply custom HTML or an optional redirect URL; otherwise the default maintenance page is used.

Maintenance exclusions allow selected client IPs to reach the backend during maintenance. IP rules and enabled username and password protection still apply. See Access Control for the combined controls and address format.

UUIDs

Default X4B error pages include a request UUID in the footer of each generated error messages (not compatible with Safari, including iOS). This UUID can be used to identify a specific request in the error log in your dashboard. This UUID is also sent to the backend server in a header defined by you if enabled (off by default), for more information see the HTTP Options documentation.

If you would like to include the request UUID in your custom error pages you may do so by including a version of the following HTML snippet in your error page:

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    entry.serverTiming.forEach((serverEntry) => {
		if(serverEntry.name == "x4b" && document.getElementById("uid").innerText.length == 0) document.getElementById("uid").innerText=serverEntry.description
    });
  });
});

["navigation", "resource"].forEach((type) =>
  observer.observe({ type, buffered: true }),
);

This will store the UUID in the element with the ID of "uid" which you can then display in your error page. You may modify this snippet to meet your needs. However note only the first observed uuid should be displayed (the failed request).

Login page override

The Login page entry uses internal identifier 525 and is served as HTTP 200. It accepts HTML only; external redirect overrides are not supported. The default template initially uses English text.

Use the shared portal script in a custom template. This example supports password sign-in, password visibility, and the optional passkey button:

<form data-x4b-auth method="post" action="/cdn-bin/x4b/auth/login">
  <input type="hidden" name="csrf" value="">
  <input type="hidden" name="return" value="/">
  <label for="username">Username</label>
  <input id="username" name="username" autocomplete="username" required>
  <label for="password">Password</label>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
  <button id="password-toggle" type="button" aria-controls="password"
          aria-pressed="false" data-show="Show password" data-hide="Hide password">Show password</button>
  <button type="submit">Sign in</button>
  <button type="button" data-x4b-passkey hidden>Sign in with a passkey</button>
</form>
<p id="login-failed" role="alert" hidden>Incorrect username or password.</p>
<p data-x4b-auth-error role="alert" hidden>Sign-in is unavailable. Reload this page and try again.</p>
<p id="passkey-error" role="alert" hidden>Passkey sign-in failed. Try again or use your password.</p>
<script src="/cdn-bin/x4b/auth/auth.js" defer></script>
<noscript>Enable JavaScript to sign in through this login page.</noscript>

Keep data-x4b-auth, the csrf and return fields, and the same-origin script URL. Leave the initial CSRF value empty: these are static HTML pages, not templates with server-replaced token placeholders. The script reads the portal's short-lived cookie context, refreshes it with a same-origin HEAD request when needed, and fills the CSRF field before submitting. JavaScript and first-party cookies must be available.

The script sets the return destination from the login URL's return query parameter, falling back to /. The server independently validates the CSRF token and restricts return destinations to local paths. Login submissions use application/x-www-form-urlencoded; keep the form's default encoding.

Failed password submissions return HTTP 303 to the login URL with #login-failed. The shared script displays login-failed on initial loading and hash changes. It also handles the password toggle above. Keep data-x4b-auth-error to show context-refresh failures rather than leaving the form silently unable to submit.

The data-x4b-passkey button and passkey-error message are optional. The shared script reveals the button only when the port offers passkeys and the browser supports them; passkeys require Login page mode and are unavailable in combined or Basic-only mode. See Access Control for enrollment, removal, and recovery. Preserve these controls if your custom page should support registered passkeys.