Custom plugins are mini web applications that add specific functionalities to the Staffbase platform. To your users, these custom plugins function very much like the standard plugins offered by Staffase. Learn more about plugins, here.
To provide real value with a custom plugin, learn more about custom plugins and how different target groups use them – from those who install and manage them, to those who finally use the custom plugins in your app or intranet. In addition, understand how custom plugins work behind the scenes.
How Administrators to Users Use a Custom Plugin
Custom plugins work in the same seamless manner as the standard plugins offered by Staffbases work. Learn more about how standard plugins work for administrators to users, here.
How a Custom Plugin Works Behind the Scenes
To understand how a custom plugin works, let’s take a look at what is happening behind the scenes:
How a Custom Plugin is Integrated into the Staffbase Platform
Custom plugins are web applications that are developed by our partners or customers. These web applications are hosted outside the Staffbase platform and embedded into the platform using iframe elements.
Once the custom plugin is deployed to the Staffbase platform, the custom plugin is available to your organization. Administrators can install the plugin, add multiple instances of the same plugin, make them available to relevant users, and, finally, manage edits and updates to the different instances of the plugin.
How a Custom Plugin Runs
There are 5 steps involved in making the content of a custom plugin available to users:
Note: Once a user tries to access the custom plugin, all the following steps happen behind the scenes automatically in a matter of seconds.
- Requesting access: The user accesses the custom plugin content on the Staffbase client. This attempt to access the content is considered as a request.
- Forwarding the request: Staffbase client forwards the user request to the identity provider, in this case, the Staffbase server.
- Redirecting the request: The identity provider appends the request with access parameters in the form of JSON Web Tokens (JWT). The appended request is redirected to the pre-defined endpoints of the host, where the custom plugin is hosted.
- Authenticating the request: The host authenticates the constraints pre-defined in the JWT and returns the response to the Staffbase client.
- Granting access: Once the Staffbase client receives the successful authorization response, the plugin content is displayed to the user.
In this process, access to the content is only granted after successful JWT authentication. This ensures that the data exchange is secure.
Different Modes of Access
The mode of access determines whether the custom plugin content is available to users who are logged in or the general public. You can choose the mode of access in the design phase, when defining the scope of the custom plugin. The different modes of access are:
- Normal mode
This is the most commonly used mode of access. In this case, the custom plugin is available only once users log in to their employee app or intranet. This mode of access ensures that the data is safe as only authorized users have access to the content.
Example of JWT request in normal mode.
- Anonymous mode
This mode does not require user credentials to process the authentication request. Anonymous mode is not often used, as organizations have only a few business use cases, where a plugin needs to be made available in the public area before users log in.
Example of JWT request in anonymous mode.