[BUG] Duplicate Domain Prevents Path‑Scoped Role Protection #391

New Issue

MrUnknownDE · 2026-04-05T17:08:35+02:00

MrUnknownDE commented

2026-04-05 17:08:35 +02:00

Originally created by @soakes on 1/9/2026

Describe the Bug

Cannot create second resource on same domain with different path prefix and role (duplicate‑domain error)

Environment

OS Type & Version: Debian 13 using Docker (v29.1.3)
Pangolin Version: ee-postgresql-latest (1.14.1)
Gerbil Version: 1.3.0
Traefik Version: v3.6.6
Newt Version: 1.8.1

To Reproduce

In Pangolin, ensure you have:
- A single domain configured, for example example.com.
- At least two roles / groups, for example:
  - admins
  - users (non‑admin)
In Pangolin, create a public resource (or application) using this domain:
- Domain: example.com
- Path prefix: / (or leave as root)
- Access / authorization: assign role/group users
- Save the resource – it is created successfully.
Attempt to create a second resource for the same domain, but scoped to an admin‑only path:
- Domain: example.com
- Path prefix: /admin
- Access / authorization: assign role/group admins only
- Try to save the new resource.
Observe that Pangolin refuses to create the second resource and displays an error similar to:

Error creating resource
Resource with that domain already

Expected Behavior

It should be possible to:

Define multiple resources on the same domain as long as they have different path prefixes (for example / and /admin).
Attach different roles / policies to different prefixes so that:
- / (or other non‑privileged paths) can be accessible to general users.
- /admin (or other admin paths) can be restricted to admins only, even though both are under example.com.

In other words, the uniqueness constraint should apply to the (domain, path prefix) pair, not just the bare domain, so that separate resources can protect different path segments under the same host.

Actual Behavior

When creating the second resource for example.com with a different path prefix (e.g. /admin) and a different role:
- Pangolin rejects the configuration and shows:
  
  Error creating resource
  Resource with that domain already
This effectively forces all traffic for that domain to be governed by a single resource and a single set of roles, which means:
- Either /admin must be left accessible to all roles assigned to the root resource, or
- The entire domain has to be locked down to admins, which is not practical when admins and non‑admins share the same host.

Additional Context

Impact / Why This Is a Bug

Many real‑world applications host multiple areas under the same domain with different access requirements, such as:

/ – public or general‑user area
/admin – sensitive administrative UI

With the current behavior:

It is not possible to express "allow only admins to /admin, but allow all users to /" using separate resources, because the second resource is blocked by the duplicate‑domain check.
Administrators are forced to:
- Either expose /admin to all users that can reach example.com, or
- Split the application across multiple domains/subdomains purely to work around the limitation.

Functionally, this feels like a bug / design oversight in the resource uniqueness logic rather than an intentional restriction, because:

The UI and configuration model both support a path prefix field.
Path prefixes are a natural place to apply separate authorization policies.

This limitation weakens security for shared domains and makes it harder to model common app layouts without restructuring DNS or the application itself.

Suggestions

The error message is technically correct (a resource already exists for that domain), but in practice too strict, because:
- The second resource uses a different path prefix and different roles.
A more flexible and intuitive model would:
- Allow multiple resources per domain as long as their path prefixes are not overlapping/conflicting, or
- At minimum allow two resources when one uses / and the other uses a more specific prefix such as /admin.
This would let administrators:
- Lock down /admin (or any other sensitive path) to admins,
- While keeping the rest of the site accessible to other roles/groups,
- Without introducing extra domains or subdomains solely for access control.

If any logs or config snippets would help troubleshoot, they can be provided as well.

*Originally created by @soakes on 1/9/2026* ### Describe the Bug Cannot create second resource on same domain with different path prefix and role (duplicate‑domain error) ### Environment - OS Type & Version: Debian 13 using Docker (v29.1.3) - Pangolin Version: [ee-postgresql-latest](https://hub.docker.com/layers/fosrl/pangolin/ee-postgresql-latest/images/sha256-19463b817189dfa030423f35b68d1956542788eeee2e7b59ee357833d92d7aa7) (1.14.1) - Gerbil Version: [1.3.0](https://hub.docker.com/layers/fosrl/gerbil/1.3.0/images/sha256-fe0e67637ae830b7ac5676d651fee1473a6ccc47245f9132542eeb4f7f6df1fd) - Traefik Version: [v3.6.6](https://hub.docker.com/layers/library/traefik/v3.6.6/images/sha256-13e903c820dfeab5cb464ca6cc9f3b276317f768e324402f440cd3472f3612b5) - Newt Version: [1.8.1](https://hub.docker.com/layers/fosrl/newt/1.8.1/images/sha256-7c72f6ec39bd674dd844387407e4ccaaca0beaaec6ac4b2991771ea1a914952b) ### To Reproduce 1. In Pangolin, ensure you have: - A **single domain** configured, for example `example.com`. - At least **two roles / groups**, for example: - `admins` - `users` (non‑admin) 2. In Pangolin, create a **public resource** (or application) using this domain: - Domain: `example.com` - Path prefix: `/` (or leave as root) - Access / authorization: assign role/group `users` - Save the resource – it is created successfully. 3. Attempt to create a **second resource** for the same domain, but scoped to an admin‑only path: - Domain: `example.com` - Path prefix: `/admin` - Access / authorization: assign role/group `admins` only - Try to save the new resource. 4. Observe that Pangolin refuses to create the second resource and displays an error similar to: > Error creating resource > Resource with that domain already ### Expected Behavior It should be possible to: - Define **multiple resources on the same domain** as long as they have **different path prefixes** (for example `/` and `/admin`). - Attach **different roles / policies to different prefixes** so that: - `/` (or other non‑privileged paths) can be accessible to general `users`. - `/admin` (or other admin paths) can be **restricted to `admins` only**, even though both are under `example.com`. In other words, the uniqueness constraint should apply to the **(domain, path prefix)** pair, not just the bare domain, so that separate resources can protect different path segments under the same host. --- ## Actual Behavior - When creating the second resource for `example.com` with a different path prefix (e.g. `/admin`) and a different role: - Pangolin rejects the configuration and shows: > Error creating resource > Resource with that domain already - This effectively forces all traffic for that domain to be governed by a **single** resource and a **single set of roles**, which means: - Either `/admin` must be left accessible to all roles assigned to the root resource, or - The entire domain has to be locked down to admins, which is not practical when admins and non‑admins share the same host. ## Additional Context ### Impact / Why This Is a Bug Many real‑world applications host multiple areas under the **same domain** with different access requirements, such as: - `/` – public or general‑user area - `/admin` – sensitive administrative UI With the current behavior: - It is **not possible** to express "allow only admins to `/admin`, but allow all users to `/`" using separate resources, because the second resource is blocked by the duplicate‑domain check. - Administrators are forced to: - Either expose `/admin` to all users that can reach `example.com`, or - Split the application across multiple domains/subdomains purely to work around the limitation. Functionally, this feels like a bug / design oversight in the resource uniqueness logic rather than an intentional restriction, because: - The UI and configuration model both support a **path prefix** field. - Path prefixes are a natural place to apply separate authorization policies. This limitation weakens security for shared domains and makes it harder to model common app layouts without restructuring DNS or the application itself. ### Suggestions - The error message is technically correct (a resource already exists for that domain), but in practice **too strict**, because: - The second resource uses a **different path prefix** and **different roles**. - A more flexible and intuitive model would: - Allow multiple resources per domain as long as their **path prefixes are not overlapping/conflicting**, or - At minimum allow two resources when one uses `/` and the other uses a **more specific prefix** such as `/admin`. - This would let administrators: - Lock down `/admin` (or any other sensitive path) to admins, - While keeping the rest of the site accessible to other roles/groups, - Without introducing extra domains or subdomains solely for access control. If any logs or config snippets would help troubleshoot, they can be provided as well.

MrUnknownDE closed this issue

2026-04-05 17:08:35 +02:00

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/dev-minor-updates-b4e5d6b9c5

revert-2766-feature/systemd-install-instructions

dependabot/npm_and_yarn/prod-patch-updates-05702d39f2

dependabot/npm_and_yarn/next-16.2.1

dependabot/npm_and_yarn/recharts-3.8.1

alerting-rules

private-site-ha

dependabot/docker/docker/library/node-25-slim

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pangolin#391