How to match route when hostname is not known at compile time and simply matching by . is not possible?

[arathunku]

I hope nobody will mind me resurrecting old thread instead of creating another one for very similar problem.

Does anyone have any working example where the hostname is not known at compile time and simply matching by . is not possible? Example: dynamic ad-hoc PR envs with some hash in the domain name. myapp-{{random string}}.example.comI found a workaround with replacing “host” on conn and it matched the route, but LiveView fails match in phoenix_live_view/lib/phoenix_live_view/route.ex at main · phoenixframework/phoenix_live_view · GitHub and keeps reconnecting.

[sodapopcan]

Matching all subdomains in Phoenix routing

In short, the “match any subdomain” clause in the router is to just not specify the :host option. The subdomain itself will be available in conn.host so you could pull it out in a plug and do whatever you need to do with it. If you want different routes depending on the presence of a subdomain, that’s a little different. There are a few discussions around here about it but I’m having trouble finding the ones I found helpful. I do have the (abandon) project I was using it in, though. In sho…

(I forgot where I originally got this code from, I know it was on this forum somewhere)

[arathunku]

I don’t want to match any subdomain, but more like

scope "/", host: "foo-*.example.com" do
end
scope "/", host: "bar-*.example.com" do
end

Yes… scopes are just patterns matchers under the hood, so that wouldn’t be possible, but

scope "/", host: "foo-*" do
end
scope "/", host: "bar-*" do
end

Is also not possible, only full subdomain with . works

[hauleth]

You will need to write Plug that runs before your router and that translates from domain to path route.

[LostKobrakai]

@arathunku

scope "/", host: "foo-*" do
end
scope "/", host: "bar-*" do
end

Is also not possible, only full subdomain with . works

That sounds like a limitation, which could be lifted, but also could you use something like foo.<uuid>.…?

@hauleth

You will need to write Plug that runs before your router and that translates from domain to path route.

That doesn’t work if this is supposed to work with LV. Socket connections do not run on the plug pipeline, so their host value will differ to the one used on the static connection, making LiveViews call to Phoenix.Router.route_info/4 fail.

[rhcarvalho]

@LostKobrakai

Socket connections do not run on the plug pipeline

I understand when @hauleth said “before the router” it means the Plug would be referenced in the endpoint.ex file, and could be also before the socket definitions.

[LostKobrakai]

The socket definition is not a plug though. All it does runs before the endpoint enters it’s own plug pipeline. Feel free to take a look at more detail here:

Phoenix.Router based socket routing (#6142)

[arathunku]

#TIL about this PR! I linked to phoenix_live_view/lib/phoenix_live_view/route.ex at main · phoenixframework/phoenix_live_view · GitHub in my original question, it also doesn’t take into account plug processing. The URL for matching/validation comes from LV payload if I’m reading the code correctly.

also could you use something like foo.<uuid>.…?

I’d rather not change my established domain prefixes and how rest of the infrastructure and other apps work to just to get to “.uuid”. It’s one of many apps, with rest of the system already in place. I’ll probably raise a ticket to remove this limitation, I’m just worried that it could be a dangerous breaking change for other plug users. Plug support would be so much better…

[LostKobrakai]

@arathunku

I’ll probably raise a ticket to remove this limitation, I’m just worried that it could be a dangerous breaking change for other plug users.

To me this looks mostly like a sanity check. If in the end you do "foo." <> _rest or "foo" <> _rest shouldn’t break anything.

[arathunku]

I raised my issue on Plug repo Extend support for routing based on host · Issue #1299 · elixir-plug/plug · GitHub

[rhcarvalho]

Oh yeah, that’s right! I forgot. I remember coming across your PR from other threads, as usual you know what you’re talking about thanks!

In my app, I do host-to-X-header translation outside of the BEAM (for historical reasons), and use the X-header (through different code paths) for both regular routes and LiveView (plug pipeline on the relevant routes, on_mount callback on relevant LVs/live_session).