By default, anyone who knows your public Pusher application key can open a connection to your Pusher Channels application. This is by design: it allows you to use Pusher Channels without first installing the Pusher Server API Auth (Channels) forge component and set up an authentication or authorisation definition for the connection. This design does not introduce a security flaw since connections can only access data on channels you authorise them to subscribe to.
For more advanced use, this design has downsides. First, it makes it hard to see who is connected to your Pusher Channels application. Second, since Pusher limits you by the number of concurrent connections, you may be concerned about attackers consuming your connection quota.
Our "Authorized Connections" feature fixes these problems by enabling you to authorise every single connection to your Pusher Channels application. This feature makes it so an attacker can’t connect to your Pusher Channels application to exhaust your connection limit, as we do not count unauthorised connections towards your quota.
Pusher provides mechanisms for both authenticating and authorising users. Our definition of this is that the former identifies who a user is, while the latter controls access by a given user to specific resources.
Since OutSystems platform is the authority on who your users are and what they can access, the PusherListener widgets make calls to the Pusher Server API Auth (Channels) endpoints to supply signed authentication and authorisation tokens for the bearing user.
OutSystems users will need to be explicitly authorised to allow authentication using the Pusher Server API Auth (Channels) endpoints.
This is done by adding the "AuthorisedUser" role in the PusherChannelsAuth_API module to an OutSystems group or directly to a user.
To enable the enforcement of the "AuthorisedUser" role, the site property IsAuthorisedUserEnabled in the PusherChannelsAuth_API module needs to be set to true on a per-tenant basis.
In some situations, you may want to terminate a user’s active connections. For example, you might have a misbehaving user that you want to kick out of your application.
To disallow a user to reconnect, your application needs to reject further attempts to authenticate as that user. This is easily done because the PusherChannelsAuth_API module controls user authentication. All successful authentication and authorisation requests are logged in the "AuthTracker" entity.
Therefore, a two-step sequence is performed when banning a user using a terminate server action from the PusherChannelsAuth_API module.
A user can be banned on a specific Pusher application or they can be banned on all Pusher applications that they have an active record in the "AuthTracker" entity. When banning a user globally they additionally have a global ban status added to the "BannedUser" entity.
To allow a user to reconnect, you need to remove the ban status on the server.
There are three server actions that in the PusherChannelsAuth_API module that can be can be used to unban a user from a specific channel, from all channels that they have been banned on and to remove the global ban.
Unfortunately, this is not something that anyone or everyone can do. There are associated Roles that need to be assigned to a group or user if they need to be able to execute one of the server actions.
Role
Server Action
BanUser
TerminateConnectionsByPusherKeysId
BanUserGlobal
TerminateConnectionsEverywhere
UnbanUser
UnbanUserByBannedPusherKeysUnbanUserByPusherKeysId
UnbanUserGlobal
It is expected that the "AuthTracker" will accumulate data over time associated with inactive users or users that have had the effective AuthorisedUser role removed from their user.
There is a timer (Timer_TrimAuthTracker) in the PusherChannelsAuth_API module that can be configured and scheduled per tenant to run. The AuthTracker_EnableTrim and AuthTracker_RetentionInDays site properties control and configure the timer.