As a realtime channel provider, you can integrate with Wix to control who can receive messages on your Wix Realtime channels. When a subscriber from another app attempts a cross-app subscription to one of your channels, Wix calls your implementation to check whether that subscriber has permission to listen.
The integration is done via an app in the Wix App Market and by implementing the Realtime Permissions Provider service plugin. After the app is installed on a site, Wix calls your service whenever a subscriber from another app attempts to join one of your channels.
Implementing this service plugin lets you explicitly allow or deny access per channel for subscribers from other apps. Without a registered provider, Wix denies all cross-app subscription attempts by default.
Wix calls your service plugin when a subscriber from another app attempts a cross-app subscription to one of your app's channels or resources. The call is synchronous: Wix waits for your response before allowing or denying the subscription.
Wix uses the read value in your response to determine whether the subscriber can receive messages on the channel. Return { read: true } to allow access, or { read: false } to deny.
Wix includes the following data with every Check Subscriber Permissions call. Use this data to apply your authorization logic.
| Input | Description |
|---|---|
| Channel | The channel or resource the subscriber is joining, including the channel name and optional resourceId. |
| Subscriber | The subscriber attempting the subscription, including their type (ADMIN, MEMBER, or VISITOR) and id. |
| Requesting app ID | The app ID of the app attempting the cross-app subscription. May be empty when the app context is unavailable. |
Wix also includes standard request context (site identifiers, identity, locale) with every service plugin call. Use this context to customize your implementation's behavior for different sites, identities, and scenarios.
Your service plugin implementation must meet the following requirements:
Your service plugin must distinguish between policy denials and errors:
{ read: false } for normal policy denials. Don't throw an error to deny access.InvalidArgumentError only when the request contains invalid or missing data that prevents your service from processing it.Follow these steps to begin implementing your service plugin.
You can implement this service plugin with the following frameworks:
To configure and customize your plugin, provide the required information in the service plugin configuration file. You can configure your plugin in your app's dashboard. For details, see Realtime Permissions Provider Extension Configuration.
Use realtimePermissionsProvider.provideHandlers() to define the following handler functions that implement your custom authorization logic. Make sure you define all required functions.
| Method | Required |
|---|---|
checkSubscriberPermissions() | Yes |
The following examples show the basic code structure for implementing the Realtime Permissions Provider service plugin.