Plugin feature registration
editPlugin feature registration
editIf your plugin will be used with Kibana’s default distribution, then you have the ability to register the features that your plugin provides. Features are typically apps in Kibana; once registered, you can toggle them via Spaces, and secure them via Roles when security is enabled.
UI Capabilities
editRegistering features also gives your plugin access to “UI Capabilities”. These capabilities are boolean flags that you can use to conditionally render your interface, based on the current user’s permissions. For example, you can hide or disable a Save button if the current user is not authorized.
Registering a feature
editFeature registration is controlled via the built-in xpack_main
plugin. To register a feature, call xpack_main
's registerFeature
function from your plugin’s init
function, and provide the appropriate details:
init(server) { const xpackMainPlugin = server.plugins.xpack_main; xpackMainPlugin.registerFeature({ // feature details here. }); }
Feature details
editRegistering a feature consists of the following fields. For more information, consult the feature registry interface.
Field name | Data type | Example | Description |
---|---|---|---|
|
|
|
A unique identifier for your feature. Usually, the ID of your plugin is sufficient. |
|
|
|
A human readable name for your feature. |
|
|
|
An array of applications this feature enables. Typically, all of your plugin’s apps (from |
|
The set of privileges this feature requires to function. |
||
|
|
"discoverApp" |
An EUI Icon to use for this feature. |
|
|
"sample_app" |
The ID of the navigation link associated with your feature. |
Privilege definition
editThe privileges
section of feature registration allows plugins to implement read/write and read-only modes for their applications.
For a full explanation of fields and options, consult the feature registry interface.
Using UI Capabilities
editUI Capabilities are available to your public (client) plugin code. These capabilities are read-only, and are used to inform the UI. This object is namespaced by feature id. For example, if your feature id is “foo”, then your UI Capabilities are stored at uiCapabilities.foo
.
To access capabilities, import them from ui/capabilities
:
import { uiCapabilities } from 'ui/capabilities'; const canUserSave = uiCapabilities.foo.save; if (canUserSave) { // show save button }
Example 1: Canvas Application
editinit(server) { const xpackMainPlugin = server.plugins.xpack_main; xpackMainPlugin.registerFeature({ id: 'canvas', name: 'Canvas', icon: 'canvasApp', navLinkId: 'canvas', app: ['canvas', 'kibana'], catalogue: ['canvas'], privileges: { all: { savedObject: { all: ['canvas-workpad'], read: ['index-pattern'], }, ui: ['save'], }, read: { savedObject: { all: [], read: ['index-pattern', 'canvas-workpad'], }, ui: [], }, }, }); }
This shows how the Canvas application might register itself as a Kibana feature.
Note that it specifies different savedObject
access levels for each privilege:
-
Users with read/write access (
all
privilege) need to be able to read/writecanvas-workpad
saved objects, and they need read-only access toindex-pattern
saved objects. -
Users with read-only access (
read
privilege) do not need to have read/write access to any saved objects, but instead get read-only access toindex-pattern
andcanvas-workpad
saved objects.
Additionally, Canvas registers the canvas
UI app and canvas
catalogue entry. This tells Kibana that these entities are available for users with either the read
or all
privilege.
The all
privilege defines a single “save” UI Capability. To access this in the UI, Canvas could:
import { uiCapabilities } from 'ui/capabilities'; const canUserSave = uiCapabilities.canvas.save; if (canUserSave) { // show save button }
Because the read
privilege does not define the save
capability, users with read-only access will have their uiCapabilities.canvas.save
flag set to false
.
Example 2: Dev Tools
editinit(server) { const xpackMainPlugin = server.plugins.xpack_main; xpackMainPlugin.registerFeature({ id: 'dev_tools', name: i18n.translate('xpack.main.featureRegistry.devToolsFeatureName', { defaultMessage: 'Dev Tools', }), icon: 'devToolsApp', navLinkId: 'kibana:dev_tools', app: ['kibana'], catalogue: ['console', 'searchprofiler', 'grokdebugger'], privileges: { all: { api: ['console'], savedObject: { all: [], read: [], }, ui: ['show'], }, read: { api: ['console'], savedObject: { all: [], read: [], }, ui: ['show'], }, }, privilegesTooltip: i18n.translate('xpack.main.featureRegistry.devToolsPrivilegesTooltip', { defaultMessage: 'User should also be granted the appropriate Elasticsearch cluster and index privileges', }), }); }
Unlike the Canvas example above, Dev Tools does not require access to any saved objects to function. Dev Tools does specify an API endpoint, however. When this is configured, the Security plugin will automatically authorize access to any server API route that is tagged with access:console
, similar to the following:
server.route({ path: '/api/console/proxy', method: 'POST', config: { tags: ['access:console'], handler: async (req, h) => { // ... } } });