pusher/pusher-http-ruby

Request: attribute accessor to the cluster config for Pusher Client

vsai opened this issue · 5 comments

vsai commented

In my pusher initializer, I specified the cluster that I'd be user.

On the client side, when I have to create the Pusher object in javascript, I would like to access the cluster specified on the server side.

const pusher = new Pusher('<%= Pusher.key %>', {
  cluster: '', // want to do '<%= Pusher.cluster %>', instead of re-specifying the cluster
  encrypted: true,
})

It is possible to access Pusher.host, but for the above client side configuration, I need the cluster.

Ideally, we can also access Pusher.encrypted, so the client side configuration can pull directly from the PusherClient.

deanlateral commented

+1, please add this :)

  • 😄1
annzenkina commented

Thanks for submitting an issue and sorry for a delay in getting back to you. Following this: https://github.com/pusher/pusher-http-ruby#global-configuration
would it be possible to call <%= Pusher.cluster %> in your client then?

Alternatively you can use Rails Custom Credentials: https://edgeguides.rubyonrails.org/security.html#custom-credentials so that config values like key, cluster, etc. would be available and shared in both server and client.

annzenkina commented

I'm going to close this issue, but let me know if there is any reason why you can't use the recommended approach.

nertzy commented

See #158, calling Pusher.cluster does not work.

elverkilde commented

After thinking about this for a bit I have come to the realisation that this feature can't be implemented, given how this SDK works.

There are basically 2 possibilities:

  • You specify the host option. This is mostly for special use cases, such as sending requests to localhost or another service (there are wire-compatible implementations of Pusher).
  • You specify the cluster parameter. This is the normal and recommended use case for Pusher users.

In the case of host, this can literally be any valid URI, e.g. localhost. In that case, there is no way for us to extract the cluster part, because there is no clear definition of "cluster".

In the case where cluster is set, the user has provided this. If the user wants to pass this on to the JS client, she can simply store the cluster parameter she already provided.

In other words, the use case described here is either easily achievable or does not make sense. Additionally, the encrypted parameter refers to TLS (HTTPS) encryption, and is not relevant for the JS client. They do not have to agree on this and in most cases you probably just want to use encryption (on both the Ruby server and JS client).