Yasoob01

Yasoob01

TL;DR

Clients join a simple topic like "daily_agent_stats:total_inbound_calls".
On the server I expand it using workspace_id + agent_id from params.
But Phoenix still subscribes them to the raw topic too → I want to stop that and only keep the expanded subscription.


Hey folks :waving_hand:

I’m building a Phoenix channel for agent analytics stats.
Here’s a simplified version of my use case:

What I want

  • Clients connect with workspace_id and agent_id as query params.

  • Then they only subscribe with a simplified topic (no need to repeat IDs).

  • On the server, I expand that simplified topic into the full PubSub key and subscribe internally.

Example

Channel:

defmodule MyAppWeb.AgentChannel do
  use Phoenix.Channel

  # Client joins something like: "daily_agent_stats:total_inbound_calls"
  def join("daily_agent_stats:" <> stat_key, _payload, socket) do
    workspace_id = socket.assigns[:workspace_id]
    agent_id = socket.assigns[:agent_id]

    # Expand topic internally
    full_topic = "agent/analytics/daily_agent_stats:#{workspace_id}:#{agent_id}:#{stat_key}"

    IO.puts("Subscribing to #{full_topic}")
    Phoenix.PubSub.subscribe(MyApp.PubSub, full_topic)

    {:ok, socket}
  end

  def join(topic, _payload, _socket) do
    {:error, %{reason: "Invalid topic #{topic}"}}
  end
end

UserSocket:

defmodule MyAppWeb.UserSocket do
  use Phoenix.Socket

  channel "daily_agent_stats:*", MyAppWeb.AgentChannel

  def connect(%{"workspace_id" => ws_id, "agent_id" => agent_id}, socket, _connect_info) do
    {:ok, assign(socket, :workspace_id, ws_id) |> assign(:agent_id, agent_id)}
  end

  def id(_socket), do: nil
end

Client connection (via wscat):

wscat -c "ws://localhost:4000/v1/agent/websocket?workspace_id=c8f4a3a0-835d-4ee2-9c71-0c18550680e5&agent_id=47dbbab6-1abf-4392-a42f-dbde107c2793"

Join a topic without IDs:

{"topic":"daily_agent_stats:total_inbound_calls","event":"phx_join","payload":{},"ref":1}

The Issue:

Even though I subscribe manually inside join/3, Phoenix still also assigns the socket to the original "daily_agent_stats:total_inbound_calls" topic.

So the socket ends up listening on two topics:

  • "daily_agent_stats:total_inbound_calls"

  • "agent/analytics/daily_agent_stats:<workspace_id>:<agent_id>:total_inbound_calls"

I want to disable the first (auto) subscription and only rely on the expanded one.

My Question:
Is there a way to tell Phoenix not to subscribe the socket to the raw topic passed in by the client, so I can fully control subscriptions in join/3?

Any guidance on best practices here would be super helpful.

Showing Posts 1 to 3

LostKobrakai

LostKobrakai

No. Channels are not an abstraction for communication between only the client and the server (1 to 1). They’re an abstraction to extend phoenix pubsub from just reaching processes on servers to their connected clients – it’s still pubsub on the channels topic.

If you want plain websockets without the semantics of channels take a look at: Bare Websockets | Benjamin Milde

Alternatively you could also make the client join the correct topic directly.

Yasoob01

Yasoob01 OP

Thanks, that makes sense. If I stick with channels, is there a recommended way to avoid exposing sensitive IDs (like workspace_id, agent_id) in the topic string? Or is the expectation that topics are not security boundaries and I should enforce authorization only in join/3?

benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Yeah consider topics almost like URLs. In general a secret URL isn’t great security, you instead should perform a real authZ check on join.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
maennchen
:warning: Security advisory: Decimal DoS vulnerability A vulnerability has been published for decimal where very large exponents can cau...
New
marciol
It would be helpful to have a list of companies worldwide that hire engineers without prior experience in Elixir. Often, it can be quite ...
New
durvia
Anyone running long-lived stateful processes on BEAM? We’re building an AI agent runtime and would love to compare notes. We’re a small ...
New

Other Trending Topics Top

marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews