github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 13:49:15 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #1360] Inconsistent Subdomain Validation: Some Domains Accept Hyphens, Others Reject Them #1874

New Issue
Closed
opened 2026-04-16 08:43:59 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-16 08:43:59 -05:00
Owner
Copy Link

Originally created by @diazhernawan on GitHub (Aug 27, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1360

I run into some inconsistent Subdomain Validation: Some Domains Accept Hyphens, Others Reject Them

  • Pangolin Version: 1.9.0
  • Gerbil Version: 1.2.0
  • Traefik Version: 3.5
  • Deployment: Self-hosted with Docker Compose

Problem Description

Pangolin's subdomain validation behaves inconsistently across different configured domains. Some domains accept hyphenated subdomains while others reject them, despite identical configuration.

Expected Behavior

All domains configured with identical settings should have consistent subdomain validation rules.

Actual Behavior

  • Domains that accept hyphens: katawarna.org, daging.co.id
  • Domains that reject hyphens: arkterra.id, bbfmeatshop.co.id, politekniktempo.com

Steps to Reproduce

  1. Configure multiple domains in Pangolin config with identical settings
  2. Attempt to create hyphenated subdomains (e.g., test-new-hyphen) for each domain
  3. Observe inconsistent validation behavior

Test Results

Working Examples (Accepted)

  • nextcloud.katawarna.org ✓
  • onlyoffice.katawarna.org ✓
  • test-new-tes-ts-test-tes-test.katawarna.org ✓
  • test-new-tes-ts-test-tes-test.daging.co.id ✓

Failing Examples (Rejected)

  • dev01-web-bbf.arkterra.id ✗ (reverts to base domain)
  • dev02-web.arkterra.id ✗ (reverts to base domain)
  • test-hyphen.bbfmeatshop.co.id ✗ (reverts to base domain)

Validation Inconsistency

Previously working subdomain dev01-web-bbf.arkterra.id was accepted, then later rejected when attempting to recreate it, suggesting validation rules changed during runtime.

Configuration

domains:
    domain1:
        base_domain: "katawarna.org"
        cert_resolver: "letsencrypt"
        prefer_wildcard_cert: true
    domain2:
        base_domain: "arkterra.id"  
        cert_resolver: "letsencrypt"
        prefer_wildcard_cert: true
    domain3:
        base_domain: "bbfmeatshop.co.id"
        cert_resolver: "letsencrypt"
    domain4:
        base_domain: "politekniktempo.com"
        cert_resolver: "letsencrypt"
    domain5:
        base_domain: "daging.co.id"
        cert_resolver: "letsencrypt"

All domains use identical DNS configuration (Cloudflare DNS-only mode, wildcard A records) and identical SSL settings.

Impact

  • Inconsistent user experience across domains
  • Some domains unusable for complex subdomain naming schemes
  • No clear documentation explaining different validation rules per domain

Additional Notes

  • Non-hyphenated subdomains work consistently across all domains
  • The validation appears domain-specific rather than organization-specific
  • No error messages or logs indicate why certain domain/subdomain combinations are rejected
Originally created by @diazhernawan on GitHub (Aug 27, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1360 I run into some inconsistent Subdomain Validation: Some Domains Accept Hyphens, Others Reject Them - **Pangolin Version**: 1.9.0 - **Gerbil Version**: 1.2.0 - **Traefik Version**: 3.5 - **Deployment**: Self-hosted with Docker Compose ## Problem Description Pangolin's subdomain validation behaves inconsistently across different configured domains. Some domains accept hyphenated subdomains while others reject them, despite identical configuration. ## Expected Behavior All domains configured with identical settings should have consistent subdomain validation rules. ## Actual Behavior - **Domains that accept hyphens**: `katawarna.org`, `daging.co.id` - **Domains that reject hyphens**: `arkterra.id`, `bbfmeatshop.co.id`, `politekniktempo.com` ## Steps to Reproduce 1. Configure multiple domains in Pangolin config with identical settings 2. Attempt to create hyphenated subdomains (e.g., `test-new-hyphen`) for each domain 3. Observe inconsistent validation behavior ## Test Results ### Working Examples (Accepted) - `nextcloud.katawarna.org` ✓ - `onlyoffice.katawarna.org` ✓ - `test-new-tes-ts-test-tes-test.katawarna.org` ✓ - `test-new-tes-ts-test-tes-test.daging.co.id` ✓ ### Failing Examples (Rejected) - `dev01-web-bbf.arkterra.id` ✗ (reverts to base domain) - `dev02-web.arkterra.id` ✗ (reverts to base domain) - `test-hyphen.bbfmeatshop.co.id` ✗ (reverts to base domain) ### Validation Inconsistency Previously working subdomain `dev01-web-bbf.arkterra.id` was accepted, then later rejected when attempting to recreate it, suggesting validation rules changed during runtime. ## Configuration ```yaml domains: domain1: base_domain: "katawarna.org" cert_resolver: "letsencrypt" prefer_wildcard_cert: true domain2: base_domain: "arkterra.id" cert_resolver: "letsencrypt" prefer_wildcard_cert: true domain3: base_domain: "bbfmeatshop.co.id" cert_resolver: "letsencrypt" domain4: base_domain: "politekniktempo.com" cert_resolver: "letsencrypt" domain5: base_domain: "daging.co.id" cert_resolver: "letsencrypt" ``` All domains use identical DNS configuration (Cloudflare DNS-only mode, wildcard A records) and identical SSL settings. ## Impact - Inconsistent user experience across domains - Some domains unusable for complex subdomain naming schemes - No clear documentation explaining different validation rules per domain ## Additional Notes - Non-hyphenated subdomains work consistently across all domains - The validation appears domain-specific rather than organization-specific - No error messages or logs indicate why certain domain/subdomain combinations are rejected
GiteaMirror added the stale label 2026-04-16 08:43:59 -05:00
GiteaMirror commented 2026-04-16 08:44:00 -05:00
Author
Owner
Copy Link

@Pallavikumarimdb commented on GitHub (Aug 29, 2025):

Hi @diazhernawan , I tested this scenario with only a wildcard domain using the patch from #1375 and was able to save all of the following without issues using dashboard:

  • nextcloud.katawarna.org
  • onlyoffice.katawarna.org
  • test-new-tes-ts-test-tes-test.katawarna.org
  • test-new-tes-ts-test-tes-test.daging.co.id
  • dev01-web-bbf.arkterra.id
  • dev02-web.arkterra.id
  • test-hyphen.bbfmeatshop.co.id

Could you please try this patch on your setup and let me know if it resolves the issue? Also, just to clarify, are you using only wildcard A records for your DNS setup, or do you also have NS/CNAME records in place? This detail would make debugging much clearer, as I can see different domain types (ns, wildcard, cname) have slightly different validation logic in the codebase. Wildcard domains have an extra validation step that NS domains don't have.

<!-- gh-comment-id:3238349189 --> @Pallavikumarimdb commented on GitHub (Aug 29, 2025): Hi @diazhernawan , I tested this scenario with only a wildcard domain using the patch from #1375 and was able to save all of the following without issues using dashboard: * `nextcloud.katawarna.org` * `onlyoffice.katawarna.org` * `test-new-tes-ts-test-tes-test.katawarna.org` * `test-new-tes-ts-test-tes-test.daging.co.id` * `dev01-web-bbf.arkterra.id` * `dev02-web.arkterra.id` * `test-hyphen.bbfmeatshop.co.id` Could you please try this patch on your setup and let me know if it resolves the issue? Also, just to clarify, are you using only wildcard A records for your DNS setup, or do you also have NS/CNAME records in place? This detail would make debugging much clearer, as I can see different domain types (ns, wildcard, cname) have slightly different validation logic in the codebase. Wildcard domains have an extra validation step that NS domains don't have.
GiteaMirror commented 2026-04-16 08:44:01 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 13, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3287234958 --> @github-actions[bot] commented on GitHub (Sep 13, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#1874
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?