Mercure publishes to topic JWT token should not be allowed to

[mariuseliassen]

Mercure version: 0.13

Without the "private" flag on messages are being sent to subscriber even if topic is not in subscriber or publish allowed whitelist.

Token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJtZXJjdXJlIjp7InB1Ymxpc2giOlsiL3dvcmtzcGFjZXMvMTIzIl0sInN1YnNjcmliZSI6WyIvd29ya3NwYWNlcy8xMjMiXX19.bxyELLWxI60AUT1xC3OR0cU_62vRUV0WVyuj00EDWjs

Unauthorized is only thrown if "Private" is ticked.
This does not work well for client-to-client mercure applications as this can be overwritten by any client.

[dunglas]

This is the intended behavior (as described in the spec). It's why there is the private flag: to distinguish between public and private updates.

[mariuseliassen]

@dunglas Ok thanks for your quick reply.

Can you suggest how to implement private publishing topics for client-to-client behavior or if this has to be done through a backend proxy service?

[dunglas]

I'm not sure to follow. Clients' code can set the publish flag to true too.

[mariuseliassen]

@dunglas Yes but we have a system where we can not trust the client. User can just create his own request to mercure with the same JWT token he got from our system and not set private and bypass the entire check.

Is it possible to request that we can control this private behavior with configuration?

https://github.com/dunglas/mercure/blob/main/publish.go#L49

example like

private := len(r.PostForm["private"]) != 0 || configOverridePrivateFlag

We would like to enforce this value to true always for our usecase, so that client-to-client can only publish to the topics that are encoded in the publish array. Is it possible to achieve?

[dunglas]

Good idea to add a configuration option to only allow private updates. +1 on my side. This would also prevent mistake from programmers forgetting to set the flag.

Still, I fail to understand the use case. Nothing can prevent a client to share the data it owns with another user (using another channel than Mercure if necessary). And in could any harm himself by doing so, as it already has the data.

[mariuseliassen]

Our use case is pretty simple.

We have a mercure we use as a ping service to show online state. A logged in account can send pings to other accounts on the same workspace through javascript (frontend). JWT's for mercure are produced by backend on page load. As such we would produce a jwt for the account A as follows:

{
  "mercure": {
    "publish": [
      "/workspaces/1"
    ],
    "subscribe": [
      "/workspaces/1"
    ]
  }
}

Now assume that a we have another account B with the following JWT

{
  "mercure": {
    "publish": [
      "/workspaces/2"
    ],
    "subscribe": [
      "/workspaces/2"
    ]
  }
}

By design Account B should not be able to send any pings to /workspace/1, but without this private flag set (by the client) he actually is able to send a message to topic /workspaces/1.

Now in OUR frontend code we can set private: true - this is not a problem. The problem comes in when a rogue account just takes the JWT token, takes the mercure url and uses a tool like Postman or curl to construct a ping to a workspace he/she really should not be allowed to post to by just omitting the private flag.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dunglas]

@mariuseliassen sorry for the long delay, but could you check if #620 fixes your issue, please?