[feature] Allow publish only API via HTTP (/1.1, /2, /3) for clients

[mbuptivo]

Hi. In my scenario, I have many publishers sending fire-and-forget updates to specific channels from wearables (in particular, Apple Watch) every few seconds. They simply publish to a channel without requiring any subscription. Subscribers, instead, are more capable clients leveraging WebSockets, and they are fewer in number.
In this case, the suggested way to send data is to POST directly (leveraging HTTP/2 or HTTP/3 via URLSession on Apple Watch).

The publish API would be perfect for my use case, but I’m not comfortable with the fact that the only authentication option is an API key.

The only workaround I’ve found so far is to have clients POST to the backend, and then have the backend post to Centrifugo. However, this approach has drawbacks: the backend must scale as Centrifugo usage grows, and it introduces additional costs and complexity.

I understand that APIs are generally expected to be used by backends, but a client-facing POST endpoint with JWT authentication would be perfect for my use case.

Thanks!

[FZambia]

Hello @mbuptivo

You are right that you don't want to use server API from client side - because its security model is designed for backend-to-Centrifugo communication.

You now have several ways to publish data to channels using Centrifugo:

• Use call to your own backend, which in turn calls Centrifugo server API
• Use our real-time SDKs - they all have Publish method on Client top level without creating Subscription - for example https://github.com/centrifugal/centrifuge-js/blob/2fa632b6475ad6d960e82c45dc80871b145f1dd5/src/centrifuge.ts#L308 - then on the backend you can use publish proxy feature to validate the payload on your backend, or it may be lightweight sidecar process.
• It's also possible to call your backend via real-time RPC method, and backend can publish.

I doubt we want more public interfaces from Centrifugo for publishing at this point, at least until there is a clear reason for having them.

[mbuptivo]

Hi, thanks for answering. As explained, calling backend api only to work around authentication moves the bottleneck to the backend, which may nullify centrifugo’s scalability and performance. The reason for a REST based publish transport is justified by IoT, wearables, etc with battery concerns. Moreover, a publish rest endpoint already exists, it’s only a matter of security.
I understand that introducing a new transport has a cost in terms of maintenance and tests.
Thanks for considering this.

[FZambia]

So you would like to:

• Avoid making WebSocket connection to the backend from device
• Avoid having extra hop for publish via the backend (backend call is expensive)

If we want to expose publish API in Centrifugo to be used from external clients, we should resolve various aspects:

• authentication model (who is this client?) - sth you mentioned
• authorization model (client can publish to this specific channel?)
• payload validation strategies (impossible to ignore from security perspective)
• rate limiting policy

In this perspective, I suppose you can consider sth like lightweight proxy between client and Centrifugo as part of your backend architecture, but much more efficient than the main backend itself. I suppose it should be sth smarter than just existing reverse proxies, given authorization and payload validation concerns. And rate limiting should be part of reverse proxy or load balancer.

[mbuptivo]

Yes, you’ve summarized the requirements correctly: no WebSocket support for certain special devices that only handle simpler protocols such as HTTPS POST and can only push data. The goal is to avoid heavy backend calls.

Regarding the other aspects:

• Authentication: the same JWT token provided by clients, sent in an HTTP header
• Authorization & payload validation: in my use case, this is something I can validate on the client side. I understand this may not cover all scenarios, but I’m willing to accept some trade-offs to keep performance high and shift some workload to trusted clients.

As for the lightweight proxy, it’s something I’ll need to consider if the client-side HTTP publish approach is not accepted. A solution like Caddy with JWT validation could be useful.