[BUG] Duplicate Domain Prevents Path‑Scoped Role Protection

[soakes]

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

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.

[soakes]

any update or acknowledgment?

[K0lin]

hi @soakes, i’m not entirely sure I understand the error, but what you’re trying to achieve can be configured directly from the individual site settings.

For example, suppose you want to host a service X at the domain x.domain.tld, but apply different authentication methods to different paths, such as:

x.domain.tld/

x.domain.tld/admin

This can be done from the site management page for x.domain.tld.

You can set your preferred authentication method (for example, SSO) as the default for the whole site. Then, in the Rules section, you can define path-based rules:

For the /admin path, enable authentication.

For the /* path, allow requests to pass through without authentication (using the Skip authentication option).

Make sure the rules are evaluated in the correct order:

1. /admin — Proceed with authentication

2. /* — Skip authentication

Let me know if this explanation addresses your issue. If you have any further questions on this topic or problems with the configuration, write here and I will try to help you.

Note: I'm not affiliated with the Pangolin project maintainers. The observations and requests above are based on reviewing the source code to infer how the system is expected to behave. This may not reflect all design decisions.

[soakes]

authentication

Hi @K0lin

Thanks very much for the detailed reply and taking the time to review the source code.

I appreciate the suggestion, but after double-checking the site settings, it still doesn't seem to support the use case I described. Specifically, if the site's root is configured as public (no auth required), there's no apparent way to selectively protect specific subpaths like /admin or /whatever for admin-only access.

The authentication appears to apply globally to the entire site when enabled (as expected), with only limited bypass options available afterward. For reference:

What I'm aiming for is a public-facing site where certain folders/subdirectories remain protected (e.g., root and most paths public, but /admin/* requiring SSO or role-based access). The SSO configuration seems to enforce site-wide protection first, preventing this inverse setup (protect subsets of otherwise-public sites).

Similarly, the reverse scenario isn't possible either: a private site (SSO required from root) with certain folders/dirs accessible to a different, narrower set of users (e.g., /public/* bypassing SSO entirely, or requiring separate credentials).

This kind of granular path-based protection is straightforward in HAProxy (which I've used extensively), typically via ACLs matching paths before/after auth checks. Is there a workaround in Pangolin's rules engine or elsewhere that I'm missing? Or is this a feature gap that might be worth a dedicated issue?

[K0lin]

Can you share to me the photo of your domain rules an what route want to cover with the auth which one none?

[soakes]

Can you share to me the photo of your domain rules an what route want to cover with the auth which one none?

Sure, in this case its a simple app, which is public apart from the /admin/ url in this case. While I have got a blanket drop on here atm, its only because coudlnt get it to work the way I wanted i.e admins should be able to still access this. ATM if an admin needs to access that path, you have to temp remove it from the rules, do what you need, then add back on. I really don't want to be doing that for obvious reasons.

Basically all I want in this ones case is for /admin/ to be protected by SSO but the root is still public. You can't enable the site-wide SSO as that of cause effects the whole domain. While that is expected, I am asking for just a folder to be protected by a different set of users i.e admin in this case.

[K0lin]

For a moment try with only this rules

1. Pass to auth | Path | /admin
2. Bypass Auth | Path | /

[soakes]

For a moment try with only this rules

1. Pass to auth   | Path    | /admin

2. Bypass Auth     | Path    | /

With or without the global SSO enabled?

[K0lin]

With

[K0lin]

Remove for the moment the geo restrictions

[K0lin]

The correct behaviour should be
Everyone can access to / and admin only via auth right?

[soakes]

With

Just tried both ways. It acts as no AUTH and EVERYONE can access admin, which is not what we want :)

Ref to Geo, already disabled from what you previously said.

Which would ignore all apart from what you said.

[soakes]

The only other way I could do is is go back to the IP ACL route and unblock that based on admins IP's, but this kinda defeats the object of SSO solution.

From what I can see the only possible way to do what I want, would be to either manually hack trafefik which if im going down that route, I may as well keep using HAProxy, or what I beleive is a bug/not intended, is fixed.

[soakes]

The correct behaviour should be Everyone can access to / and admin only via auth right?

Yes

example.com - Everyone can access this without SSO (i.e using built in auth of the app)
example.com/admin - ONLY admins can access via SSO from Pangolin

Even if I can get the app to be rewritten to support SSO directly rather then its built in auth system, the problem will still be that while SSO could be site wide on Pangolin, the non-admin uses would still have access to /admin. This is because the platform only supports SSO globally on the domain and only allows a single set of users which then treats it as all or nothing.

Currenly only work arounds I see is either go down a massive IP ACL route, which works for admins whos on static addresses, or blanket block like I have currently and switch it on/off when required. Its not ideal but at least the admin part of the public site is still protected (most of the time).

This is why I mentioned, this is likely a bug more then anything or a massive oversight.

[K0lin]

I' sorry for the late reply but do not insert /admin/* but insert /admin

(Sorry for the dumb question when you'll test the path use the incognito mode)

[K0lin]

And also the identity provider is correctly configured?