Pusher Channels Docs | HTTP API Referencepage (Feature Request)

[HenriqueSPin]

I don´t know if this is the right place for this. But:

Hello there, I want to suggest a feature to https://pusher.com/docs/channels/library_auth_reference/rest-api/

Add a query string param in order to send user_info and its contents in the object that returns (as of now) only the user id.

The query string param could be "with_user_info", and the API response will include the user_info attribute and its contents when with_user_info=1

[benw-pusher]

Hi @HenriqueSPin. What endpoint is it you would like to see this added to? Is this the /users endpoint at
https://pusher.com/docs/channels/library_auth_reference/rest-api/#get-users

[HenriqueSPin]

Yes! Sorry for not making it clear.

Do you think it is possible? I definitely believe this could help in a variety of use cases.

[benw-pusher]

Thanks for clarifying.

Such a change would require a change to our API along with subsequent changes to our server libraries so it is unlikely to be a feature that is added in the short term. However, I will share it with our product team for consideration in future work.

If your use case requires an understanding of the user info at the server side that doesn't currently exist then you may be able to build this out already. When a user subscribes to a presence channel an authentication request is sent to an endpoint in your system - see https://pusher.com/docs/channels/server_api/authenticating-users/. During this process you pass the user info from the client to your auth endpoint - which would allow you to store the data and look it up when required later.

[HenriqueSPin]

Sure.
But in some of our apps, we have more than one type of user and the ids alone may not be sufficient to identify it.
I came across some developers in web forums asking for this also.
If the WS server has the info and stores this state, would be nice to have a way to retrieve it anyway.

Thank you for your attention, @benw-pusher.

[benw-pusher]

You mention that the websocket servers are storing this info, which is correct. However the info that is stored here is provided by external sources in all cases - the data is provided by the authentication server per request.

As the data we hold is being supplied by your own system somewhere then it should be possible to build a data store that contains both user IDs and the additional user data that you require, without the need to query our API.

As shared, I will feed this request back to our product team but it is not likely to be implemented in the short term and so I propose the above as a possible workaround to help you achieve your goals.