Scoped servicesedit

Whenever Kibana needs to get access to data saved in Elasticsearch, it should perform a check whether an end-user has access to the data. The Kibana Platform introduced a handler interface on the server-side to perform that association internally. Core services, that require impersonation with an incoming request, are exposed via context argument of the request handler interface. as

async function handler(context, req, res) {
  const data = await context.core.elasticsearch.client.asCurrentUser('ping');

The request handler context exposes the following scoped core services:

Declare a custom scoped serviceedit

Plugins can extend the handler context with a custom API that will be available to the plugin itself and all dependent plugins. For example, the plugin creates a custom Elasticsearch client and wants to use it via the request handler context:

import type { CoreSetup, RequestHandlerContext, IScopedClusterClient } from 'kibana/server';

interface MyRequestHandlerContext extends RequestHandlerContext {
 myPlugin: {
   client: IScopedClusterClient;

class MyPlugin {
  setup(core: CoreSetup) {
    const client = core.elasticsearch.createClient('myClient');
    core.http.registerRouteHandlerContext<MyRequestHandlerContext, 'myPlugin'>('myPlugin', (context, req, res) => {
      return { client: client.asScoped(req) };
    const router = core.http.createRouter<MyRequestHandlerContext>();
      { path: '/api/my-plugin/', validate: … },
      async (context, req, res) => {
        // context type is inferred as MyPluginContext
        const data = await context.myPlugin.client.asCurrentUser('endpoint');