fix(domains): cluster-default deployments skip domain/subdomain approval#137
Merged
uittenbroekrobbert merged 1 commit intoJun 12, 2026
Merged
Conversation
A deployment with no base-domain uses the cluster-default URL -- the platform default, not a user-requested domain. The enforcer resolved a missing base-domain to next(iter(supported)) (an ARBITRARY supported domain, set-iteration order) and then ran THAT domain's subdomain restrictions against the deployment, wrongly rejecting cluster-default PR deployments: "Gebruik van een subdomein 'pr797' voor het domein 'rijksapp.dev' is op aanvraag" for a deployment that only ever used the cluster default. Resolve actual_domain to None for the cluster default, so every domain/subdomain check (dots-compat, base-domain approval, subdomain approval, availability, bare-domain) skips -- there is nothing to approve. Explicit base-domains and the "__custom__" path are unchanged and still go through approval. Regression tests: cluster-default + restricted subdomain -> no error; explicit restricted domain + unapproved subdomain -> still rejected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug (blocks PR deployments)
A colleague's new PR deployment failed with:
…for a deployment that uses the cluster default and never requested
rijksapp.dev.Root cause
In
DomainConfigEnforcer.enforce, when a deployment has no base-domain (cluster default),actual_domainwas resolved to:That arbitrary domain happened to be
rijksapp.dev— a subdomain-restricted platform domain — so the subdomain-approval check ran its restrictions against a cluster-default deployment and rejected it. (Most regel-k4c PRs predate the API enforcer, so pr797 was just the first new one to hit it.)Fix
Resolve
actual_domain = Nonefor the cluster default. There is no user-chosen domain to validate, so everyif actual_domain …check (dots-compat, base-domain approval, subdomain approval, availability, bare-domain) naturally skips — the cluster default is always allowed. Explicit base-domains and__custom__are unchanged and still go through approval.Tests
cluster-default + restricted subdomain→ no error (fails on pre-fix code).explicit restricted domain + unapproved subdomain→ still rejected (feature intact).So the answer to "moeten we iets veranderen aan onze URL-strategie?" is no — the URL strategy is fine; this was a validation bug. Cluster-default PRs deploy normally once this ships.