Skip to content

Fix check for valid custom pages domains

What does this MR do and why?

This MR fixes the check for valid custom pages domains (#349066) by essentially reverting one change of 8df7bcf532c9f0407fcefa12d205cb9d160fe5f4.

That change was unrelated to what the commit message of that commit says:

Allow numeric pages domain

Previously, PagesDomain would not allow a domain such as 123.example.com. With this change, this is now allowed, because it is a perfectly valid domain.

After the change of this MR, only actual subdomains of the pages domain and the pages domain itself are disallowed as custom domains. Notably, domains that simply have gitlab.io as a suffix (like test-gitlab.io) are allowed, as is the bare pages domain (gitlab.io).

🛠 with at Siemens

Closes #349066

Screenshots

The following screenshots show the old and new behavior with the pages domain set to 127.0.0.1.nip.io:

test old new
subdomain image image
domain with pages domain as suffix image image

How to set up and validate locally

Assuming 127.0.0.1.nip.io as pages domain.

  1. Ensure that GitLab Pages and custom domains is enabled for the test instance. (Set pages.external_http to 127.0.0.1.nip.io in gitlab/config/gitlab.yml when using GDK.)
  2. Go to any project, then to Settings -> Pages -> New Domain (e.g., http://127.0.0.1:3000/root/test/pages/domains).
  3. Configure some domain with the pages domain as a suffix, e.g., test-127.0.0.1.nip.io. Verify that no error occurs.
  4. Configure some subdomain of the pages domain, e.g., test.127.0.0.1.nip.io. Verify that an error does occur.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Markus Legner

Merge request reports

Loading