🚀 Feature: Support path-based routing #165

New Issue

OVERLORD · 2025-10-07T00:04:21+03:00

OVERLORD commented

2025-10-07 00:04:21 +03:00

Originally created by @jcstryker on GitHub.

Feature description

Followup to https://github.com/pocket-id/pocket-id/issues/224

I am suggesting enabling support for hosting the pocket-id web app on a path other than /, e.g. https://foo.bar/auth or https://foo.bar/id

Pitch

This would enable deploying the app in environments without DNS e.g. virtual machines or docker images that only are accessible via IP - requiring apps to be routed based on path instead of subdomain.

There are other benefits to path-based routing that make it preferable in certain production environments including:

Sub-domain routing is controlled by the DNS system and therefore can be routed without requiring any input from the server hosting the site. Changes to routing have a time-lag and traffic can be manipulated if DNS is compromised in a way that is harder to detect than on a single domain.
Path-based routing is controlled by the web server and can be applied instantaneously, maintaining a tight ownership boundary for the application
Path-based routing can simplify regex matching and filtering for many reverse proxy implementations, especially those used in the Kubernetes ecosystem and enterprise use cases.

Originally created by @jcstryker on GitHub. ### Feature description Followup to https://github.com/pocket-id/pocket-id/issues/224 I am suggesting enabling support for hosting the pocket-id web app on a path other than `/`, e.g. `https://foo.bar/auth` or `https://foo.bar/id` ### Pitch This would enable deploying the app in environments without DNS e.g. virtual machines or docker images that only are accessible via IP - requiring apps to be routed based on path instead of subdomain. There are other benefits to path-based routing that make it preferable in certain production environments including: - Sub-domain routing is controlled by the DNS system and therefore can be routed without requiring any input from the server hosting the site. Changes to routing have a time-lag and traffic can be manipulated if DNS is compromised in a way that is harder to detect than on a single domain. - Path-based routing is controlled by the web server and can be applied instantaneously, maintaining a tight ownership boundary for the application - Path-based routing can simplify regex matching and filtering for many reverse proxy implementations, especially those used in the Kubernetes ecosystem and enterprise use cases.

OVERLORD added the feature label 2025-10-07 00:04:21 +03:00

OVERLORD closed this issue

2025-10-07 00:04:22 +03:00

OVERLORD commented

2025-10-07 00:04:24 +03:00

@stonith404 commented on GitHub:

Thanks for your suggestion but I agree with @ItalyPaleAle.

@stonith404 commented on GitHub: Thanks for your suggestion but I agree with @ItalyPaleAle.

OVERLORD commented

2025-10-07 00:04:24 +03:00

@jcstryker commented on GitHub:

@ItalyPaleAle - I think what you may be misunderstanding is that for some environments DNS is not available at all. We would be accessing pocket-id via IP e.g. 10.96.0.1 instead of a domain name.

@jcstryker commented on GitHub: @ItalyPaleAle - I think what you may be misunderstanding is that for some environments DNS is not available at all. We would be accessing pocket-id via IP e.g. `10.96.0.1` instead of a domain name.

OVERLORD commented

2025-10-07 00:04:24 +03:00

@jcstryker commented on GitHub:

In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination!

Setting up Traefik with an IP address instead of a DNS name would require path based routing. For some threat models - the inclusion of DNS is a larger risk than a self contained application addressed via IP.

It feels like this response is dismissive of that use case.

I recognize the complexity - but supporting this would enable some important use cases. I agree that the recommended path should be to run it on a standalone domain, but there are some valid use cases where that might not be possible.

@jcstryker commented on GitHub: >In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination! Setting up Traefik with an IP address instead of a DNS name would require path based routing. For some threat models - the inclusion of DNS is a larger risk than a self contained application addressed via IP. It feels like this response is dismissive of that use case. I recognize the complexity - but supporting this would enable some important use cases. I agree that the recommended path should be to run it on a standalone domain, but there are some valid use cases where that might not be possible.

OVERLORD commented

2025-10-07 00:04:25 +03:00

@ItalyPaleAle commented on GitHub:

Putting Pocket ID on a sub-domain comes with some security risk. Passkeys are tied to a specific domain, so you should host on a domain Pocket ID only, or some of the security offered by passkeys gets lost. (see RP-ID spec)

In addition to that, there's quite some complexity in supporting sub-paths.

In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination!

@ItalyPaleAle commented on GitHub: Putting Pocket ID on a sub-domain comes with some security risk. Passkeys are tied to a specific domain, so you should host on a domain Pocket ID **only**, or some of the security offered by passkeys gets lost. ([see RP-ID spec](https://www.w3.org/TR/webauthn-2/#rp-id)) In addition to that, there's quite some complexity in supporting sub-paths. In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination!

OVERLORD commented

2025-10-07 00:04:25 +03:00

@ItalyPaleAle commented on GitHub:

In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination!

Setting up Traefik with an IP address instead of a DNS name would require path based routing. For some threat models - the inclusion of DNS is a larger risk than a self contained application addressed via IP. It feels like this response is dismissive of that use case.

I'm not following, sorry.

My advice was to set up a single Traefik (or Caddy, or Nginx, or your preferred load balancer) in front of all containers.

For example, all services are on the domain example.com. The DNS record for *.example.com points to the Traefik server.

id.example.com points to Pocket ID
myapp.example.com points to an app

All go through Traefik and have TLS. Traefik has a wildcard TLS certificate for *.example.com (via Let's Encrypt, using the DNS01 challenge).

@ItalyPaleAle commented on GitHub: > > In your case, I would recommend setting up a load balancer like Traefik to be able to host multiple apps on the same IP/port combination! > > Setting up Traefik with an IP address instead of a DNS name would require path based routing. For some threat models - the inclusion of DNS is a larger risk than a self contained application addressed via IP. It feels like this response is dismissive of that use case. I'm not following, sorry. My advice was to set up a single Traefik (or Caddy, or Nginx, or your preferred load balancer) in front of all containers. For example, all services are on the domain `example.com`. The DNS record for `*.example.com` points to the Traefik server. - `id.example.com` points to Pocket ID - `myapp.example.com` points to an app All go through Traefik and have TLS. Traefik has a wildcard TLS certificate for `*.example.com` (via Let's Encrypt, using the DNS01 challenge).

OVERLORD commented

2025-10-07 00:04:26 +03:00

@ItalyPaleAle commented on GitHub:

I think what you may be misunderstanding is that for some environments DNS is not available at all.

Still not sure I understand. What environments can't have DNS?

You can always deploy a DNS server (like dnsmasq) yourself. Some firewalls/routers allow setting DNS records too.
If the above isn't an option, you can buy a domain like example.com and assign *.example.com to 10.96.0.1 (it's perfectly valid to assign private IPs to a public DNS name)
- FWIW this is what I do - the domain I use for my apps is a public one, but the IPs it points to are private
If the above isn't an option either, you can always fall back to modifying /etc/hosts

@ItalyPaleAle commented on GitHub: > I think what you may be misunderstanding is that for some environments DNS is not available at all. Still not sure I understand. What environments can't have DNS? - You can always deploy a DNS server (like dnsmasq) yourself. Some firewalls/routers allow setting DNS records too. - If the above isn't an option, you can buy a domain like `example.com` and assign `*.example.com` to `10.96.0.1` (it's perfectly valid to assign private IPs to a public DNS name) - FWIW this is what I do - the domain I use for my apps is a public one, but the IPs it points to are private - If the above isn't an option either, you can always fall back to modifying `/etc/hosts`

OVERLORD commented

2025-10-07 00:04:26 +03:00

@jcstryker commented on GitHub:

I agree that it is technically possible and very easy to deploy DNS. Your recommendations are very good for a majority of use-cases.

For some environments however the removal of DNS is intentional, to remove a potential attack vector or there are scalability concerns when managing the /etc/hosts file for a large fleet of machines when there is no central DNS server.

I love pocket-id and personally host it on a dedicated DNS domain similar to the setup you recommend - I also have other use cases that have some of the limitations that I mentioned that I would like to be able to bring pocket-id into to improve overall security, thus this feature request.

@jcstryker commented on GitHub: I agree that it is technically possible and very easy to deploy DNS. Your recommendations are very good for a majority of use-cases. For some environments however the removal of DNS is intentional, to remove a potential attack vector or there are scalability concerns when managing the `/etc/hosts` file for a large fleet of machines when there is no central DNS server. I love pocket-id and personally host it on a dedicated DNS domain similar to the setup you recommend - I also have other use cases that have some of the limitations that I mentioned that I would like to be able to bring pocket-id into to improve overall security, thus this feature request.

OVERLORD referenced this issue

2025-10-07 00:24:54 +03:00

[PR #165] [MERGED] fix: add save changes dialog before sending test email #933

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#165