test-solr-output.json

{
  "responseHeader":{
    "status":0,
    "QTime":0},
  "response":{"numFound":3384,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"kerberos-authentication-plugin:##DOC",
        "fileName":"kerberos-authentication-plugin",
        "title":"Kerberos Authentication Plugin",
        "path":["Kerberos Authentication Plugin"],
        "level":0,
        "hasText":false,
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin"},
      {
        "id":"kerberos-authentication-plugin:##PREAMBLE",
        "fileName":"kerberos-authentication-plugin",
        "title":"Preamble",
        "path":["Kerberos Authentication Plugin",
          "Preamble"],
        "level":0,
        "hasText":true,
        "text":["If you are using Kerberos to secure your network environment, the Kerberos authentication plugin can be used to secure a Solr cluster.",
          "This allows Solr to use a Kerberos service principal and keytab file to authenticate with ZooKeeper and between nodes of the Solr cluster (if applicable). Users of the Admin UI and all clients (such as <<using-solrj.adoc#using-solrj,SolrJ>>) would also need to have a valid ticket before being able to use the UI or send requests to Solr.",
          "Support for the Kerberos authentication plugin is available in SolrCloud mode or standalone mode."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin"},
      {
        "id":"kerberos-authentication-plugin:#security-json",
        "fileName":"kerberos-authentication-plugin",
        "title":"security.json",
        "anchor":"#security-json",
        "path":["Kerberos Authentication Plugin",
          "How Solr Works With Kerberos",
          "security.json"],
        "level":2,
        "hasText":true,
        "text":["The Solr authentication model uses a file called `security.json`. A description of this file and how it is created and maintained is covered in the section <<authentication-and-authorization-plugins.adoc#authentication-and-authorization-plugins,Authentication and Authorization Plugins>>. If this file is created after an initial startup of Solr, a restart of each node of the system is required."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#how-solr-works-with-kerberos"},
      {
        "id":"kerberos-authentication-plugin:#service-principals-and-keytab-files",
        "fileName":"kerberos-authentication-plugin",
        "title":"Service Principals and Keytab Files",
        "anchor":"#service-principals-and-keytab-files",
        "path":["Kerberos Authentication Plugin",
          "How Solr Works With Kerberos",
          "Service Principals and Keytab Files"],
        "level":2,
        "hasText":true,
        "text":["Each Solr node must have a service principal registered with the Key Distribution Center (KDC). The Kerberos plugin uses SPNego to negotiate authentication.",
          "Using `HTTP/host1@YOUR-DOMAIN.ORG`, as an example of a service principal:",
          "`HTTP` indicates the type of requests which this service principal will be used to authenticate. The `HTTP/` in the service principal is a must for SPNego to work with requests to Solr over HTTP.",
          "`host1` is the host name of the machine hosting the Solr node.",
          "`YOUR-DOMAIN.ORG` is the organization wide Kerberos realm.",
          "Multiple Solr nodes on the same host may have the same service principal, since the host name is common to them all.",
          "Along with the service principal, each Solr node needs a keytab file which should contain the credentials of the service principal used. A keytab file contains encrypted credentials to support passwordless logins while obtaining Kerberos tickets from the KDC. For each Solr node, the keytab file should be kept in a secure location and not shared with users of the cluster.",
          "Since a Solr cluster requires internode communication, each node must also be able to make Kerberos enabled requests to other nodes. By default, Solr uses the same service principal and keytab as a 'client principal' for internode communication. You may configure a distinct client principal explicitly, but doing so is not recommended and is not covered in the examples below."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#how-solr-works-with-kerberos"},
      {
        "id":"kerberos-authentication-plugin:#kerberized-zookeeper",
        "fileName":"kerberos-authentication-plugin",
        "title":"Kerberized ZooKeeper",
        "anchor":"#kerberized-zookeeper",
        "path":["Kerberos Authentication Plugin",
          "How Solr Works With Kerberos",
          "Kerberized ZooKeeper"],
        "level":2,
        "hasText":true,
        "text":["When setting up a kerberized SolrCloud cluster, it is recommended to enable Kerberos security for ZooKeeper as well.",
          "In such a setup, the client principal used to authenticate requests with ZooKeeper can be shared for internode communication as well. This has the benefit of not needing to renew the ticket granting tickets (TGTs) separately, since the ZooKeeper client used by Solr takes care of this. To achieve this, a single JAAS configuration (with the app name as Client) can be used for the Kerberos plugin as well as for the ZooKeeper client.",
          "See the <<ZooKeeper Configuration>> section below for an example of starting ZooKeeper in Kerberos mode."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#how-solr-works-with-kerberos"},
      {
        "id":"kerberos-authentication-plugin:#browser-configuration",
        "fileName":"kerberos-authentication-plugin",
        "title":"Browser Configuration",
        "anchor":"#browser-configuration",
        "path":["Kerberos Authentication Plugin",
          "How Solr Works With Kerberos",
          "Browser Configuration"],
        "level":2,
        "hasText":true,
        "text":["In order for your browser to access the Solr Admin UI after enabling Kerberos authentication, it must be able to negotiate with the Kerberos authenticator service to allow you access. Each browser supports this differently, and some (like Chrome) do not support it at all. If you see 401 errors when trying to access the Solr Admin UI after enabling Kerberos authentication, it's likely your browser has not been configured properly to know how or where to negotiate the authentication request.",
          "Detailed information on how to set up your browser is beyond the scope of this documentation; please see your system administrators for Kerberos for details on how to configure your browser."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#how-solr-works-with-kerberos"},
      {
        "id":"kerberos-authentication-plugin:#how-solr-works-with-kerberos",
        "fileName":"kerberos-authentication-plugin",
        "title":"How Solr Works With Kerberos",
        "anchor":"#how-solr-works-with-kerberos",
        "path":["Kerberos Authentication Plugin",
          "How Solr Works With Kerberos"],
        "level":1,
        "hasText":true,
        "text":["When setting up Solr to use Kerberos, configurations are put in place for Solr to use a _service principal_, or a Kerberos username, which is registered with the Key Distribution Center (KDC) to authenticate requests. The configurations define the service principal name and the location of the keytab file that contains the credentials."],
        "childrenCount":"4",
        "_nest_parent_":"kerberos-authentication-plugin"},
      {
        "id":"kerberos-authentication-plugin:#get-service-principals-and-keytabs",
        "fileName":"kerberos-authentication-plugin",
        "title":"Get Service Principals and Keytabs",
        "anchor":"#get-service-principals-and-keytabs",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Get Service Principals and Keytabs"],
        "level":2,
        "hasText":true,
        "text":["Before configuring Solr, make sure you have a Kerberos service principal for each Solr host and ZooKeeper (if ZooKeeper has not already been configured) available in the KDC server, and generate a keytab file as shown below.",
          "This example assumes the hostname is `192.168.0.107` and your home directory is `/home/foo/`. This example should be modified for your own environment.",
          "root@kdc:/# kadmin.local",
          "Authenticating as principal foo/admin@EXAMPLE.COM with password.",
          "",
          "kadmin.local:  addprinc HTTP/192.168.0.107",
          "WARNING: no policy specified for HTTP/192.168.0.107@EXAMPLE.COM; defaulting to no policy",
          "Enter password for principal \"HTTP/192.168.0.107@EXAMPLE.COM\":",
          "Re-enter password for principal \"HTTP/192.168.0.107@EXAMPLE.COM\":",
          "Principal \"HTTP/192.168.0.107@EXAMPLE.COM\" created.",
          "",
          "kadmin.local:  ktadd -k /tmp/107.keytab HTTP/192.168.0.107",
          "Entry for principal HTTP/192.168.0.107 with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/107.keytab.",
          "Entry for principal HTTP/192.168.0.107 with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/107.keytab.",
          "Entry for principal HTTP/192.168.0.107 with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/108.keytab.",
          "Entry for principal HTTP/192.168.0.107 with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/tmp/107.keytab.",
          "",
          "kadmin.local:  quit",
          "Copy the keytab file from the KDC server’s `/tmp/107.keytab` location to the Solr host at `/keytabs/107.keytab`. Repeat this step for each Solr node.",
          "You might need to take similar steps to create a ZooKeeper service principal and keytab if it has not already been set up. In that case, the example below shows a different service principal for ZooKeeper, so the above might be repeated with `zookeeper/host1` as the service principal for one of the nodes"],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#zookeeper-configuration",
        "fileName":"kerberos-authentication-plugin",
        "title":"ZooKeeper Configuration",
        "anchor":"#zookeeper-configuration",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "ZooKeeper Configuration"],
        "level":2,
        "hasText":true,
        "text":["If you are using a ZooKeeper that has already been configured to use Kerberos, you can skip the ZooKeeper-related steps shown here.",
          "Since ZooKeeper manages the communication between nodes in a SolrCloud cluster, it must also be able to authenticate with each node of the cluster. Configuration requires setting up a service principal for ZooKeeper, defining a JAAS configuration file and instructing ZooKeeper to use both of those items.",
          "The first step is to create a file `java.env` in ZooKeeper's `conf` directory and add the following to it, as in this example:",
          "export JVMFLAGS=\"-Djava.security.auth.login.config=/etc/zookeeper/conf/jaas-client.conf\"",
          "The JAAS configuration file should contain the following parameters. Be sure to change the `principal` and `keyTab` path as appropriate. The file must be located in the path defined in the step above, with the filename specified.",
          "Server {",
          " com.sun.security.auth.module.Krb5LoginModule required",
          "  useKeyTab=true",
          "  keyTab=\"/keytabs/zkhost1.keytab\"",
          "  storeKey=true",
          "  doNotPrompt=true",
          "  useTicketCache=false",
          "  debug=true",
          "  principal=\"zookeeper/host1@EXAMPLE.COM\";",
          "};",
          "Finally, add the following lines to the ZooKeeper configuration file `zoo.cfg`:",
          "authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider",
          "jaasLoginRenew=3600000",
          "Once all of the pieces are in place, start ZooKeeper with the following parameter pointing to the JAAS configuration file:",
          "bin/zkServer.sh start -Djava.security.auth.login.config=/etc/zookeeper/conf/jaas-client.conf"],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#create-security-json",
        "fileName":"kerberos-authentication-plugin",
        "title":"Create security.json",
        "anchor":"#create-security-json",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Create security.json"],
        "level":2,
        "hasText":true,
        "text":["Create the `security.json` file.",
          "In SolrCloud mode, you can set up Solr to use the Kerberos plugin by uploading the `security.json` to ZooKeeper while you create it, as follows:",
          "server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put /security.json '{\"authentication\":{\"class\": \"org.apache.solr.security.KerberosPlugin\"}}'",
          "If you are using Solr in standalone mode, you need to create the `security.json` file and put it in your `$SOLR_HOME` directory.",
          "More details on how to use a `/security.json` file in Solr are available in the section <<authentication-and-authorization-plugins.adoc#authentication-and-authorization-plugins,Authentication and Authorization Plugins>>."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#define-a-jaas-configuration-file",
        "fileName":"kerberos-authentication-plugin",
        "title":"Define a JAAS Configuration File",
        "anchor":"#define-a-jaas-configuration-file",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Define a JAAS Configuration File"],
        "level":2,
        "hasText":true,
        "text":["The JAAS configuration file defines the properties to use for authentication, such as the service principal and the location of the keytab file. Other properties can also be set to ensure ticket caching and other features.",
          "The following example can be copied and modified slightly for your environment. The location of the file can be anywhere on the server, but it will be referenced when starting Solr so it must be readable on the filesystem. The JAAS file may contain multiple sections for different users, but each section must have a unique name so it can be uniquely referenced in each application.",
          "In the below example, we have created a JAAS configuration file with the name and path of `/home/foo/jaas-client.conf`. We will use this name and path when we define the Solr start parameters in the next section. Note that the client `principal` here is the same as the service principal. This will be used to authenticate internode requests and requests to ZooKeeper. Make sure to use the correct `principal` hostname and the `keyTab` file path.",
          "Client {",
          "  com.sun.security.auth.module.Krb5LoginModule required",
          "  useKeyTab=true",
          "  keyTab=\"/keytabs/107.keytab\"",
          "  storeKey=true",
          "  useTicketCache=true",
          "  debug=true",
          "  principal=\"HTTP/192.168.0.107@EXAMPLE.COM\";",
          "};",
          "The first line of this file defines the section name, which will be used with the `solr.kerberos.jaas.appname` parameter, defined below.",
          "The main properties we are concerned with are the `keyTab` and `principal` properties, but there are others which may be required for your environment. The https://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html[javadocs for the Krb5LoginModule] (the class that's being used and is called in the second line above) provide a good outline of the available properties, but for reference the ones in use in the above example are explained here:",
          "`useKeyTab`: this boolean property defines if we should use a keytab file (true, in this case).",
          "`keyTab`: the location and name of the keytab file for the principal this section of the JAAS configuration file is for. The path should be enclosed in double-quotes.",
          "`storeKey`: this boolean property allows the key to be stored in the private credentials of the user.",
          "`useTicketCache`: this boolean property allows the ticket to be obtained from the ticket cache.",
          "`debug`: this boolean property will output debug messages for help in troubleshooting.",
          "`principal`: the name of the service principal to be used."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#solr-startup-parameters",
        "fileName":"kerberos-authentication-plugin",
        "title":"Solr Startup Parameters",
        "anchor":"#solr-startup-parameters",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Solr Startup Parameters"],
        "level":2,
        "hasText":true,
        "text":["While starting up Solr, the following host-specific parameters need to be passed. These parameters can be passed at the command line with the `bin/solr` start command (see <<solr-control-script-reference.adoc#solr-control-script-reference,Solr Control Script Reference>> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system.",
          "`solr.kerberos.name.rules`",
          "Used to map Kerberos principals to short names. Default value is `DEFAULT`. Example of a name rule: `RULE:[1:$1@$0](.\\*EXAMPLE.COM)s/@.*//`.",
          "`solr.kerberos.cookie.domain`",
          "Used to issue cookies and should have the hostname of the Solr node. This parameter is required.",
          "`solr.kerberos.cookie.portaware`",
          "When set to `true`, cookies are differentiated based on host and port, as opposed to standard cookies which are not port aware. This should be set if more than one Solr node is hosted on the same host. The default is `false`.",
          "`solr.kerberos.principal`",
          "The service principal. This parameter is required.",
          "`solr.kerberos.keytab`",
          "Keytab file path containing service principal credentials. This parameter is required.",
          "`solr.kerberos.jaas.appname`",
          "The app name (section name) within the JAAS configuration file which is required for internode communication. Default is `Client`, which is used for ZooKeeper authentication as well. If different users are used for ZooKeeper and Solr, they will need to have separate sections in the JAAS configuration file.",
          "`java.security.auth.login.config`",
          "Path to the JAAS configuration file for configuring a Solr client for internode communication. This parameter is required.",
          "Here is an example that could be added to `bin/solr.in.sh`. Make sure to change this example to use the right hostname and the keytab file path.",
          "SOLR_AUTH_TYPE=\"kerberos\"",
          "SOLR_AUTHENTICATION_OPTS=\"-Djava.security.auth.login.config=/home/foo/jaas-client.conf -Dsolr.kerberos.cookie.domain=192.168.0.107 -Dsolr.kerberos.cookie.portaware=true -Dsolr.kerberos.principal=HTTP/192.168.0.107@EXAMPLE.COM -Dsolr.kerberos.keytab=/keytabs/107.keytab\""],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#using-delegation-tokens",
        "fileName":"kerberos-authentication-plugin",
        "title":"Using Delegation Tokens",
        "anchor":"#using-delegation-tokens",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Using Delegation Tokens"],
        "level":2,
        "hasText":true,
        "text":["The Kerberos plugin can be configured to use delegation tokens, which allow an application to reuse the authentication of an end-user or another application.",
          "There are a few use cases for Solr where this might be helpful:",
          "Using distributed clients (such as MapReduce) where each client may not have access to the user's credentials.",
          "When load on the Kerberos server is high. Delegation tokens can reduce the load because they do not access the server after the first request.",
          "If requests or permissions need to be delegated to another user.",
          "To enable delegation tokens, several parameters must be defined. These parameters can be passed at the command line with the `bin/solr` start command (see <<solr-control-script-reference.adoc#solr-control-script-reference,Solr Control Script Reference>> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system.",
          "`solr.kerberos.delegation.token.enabled`",
          "This is `false` by default, set to `true` to enable delegation tokens. This parameter is required if you want to enable tokens.",
          "`solr.kerberos.delegation.token.kind`",
          "The type of delegation tokens. By default this is `solr-dt`. Likely this does not need to change. No other option is available at this time.",
          "`solr.kerberos.delegation.token.validity`",
          "Time, in seconds, for which delegation tokens are valid. The default is 36000 seconds.",
          "`solr.kerberos.delegation.token.signer.secret.provider`",
          "Where delegation token information is stored internally. The default is `zookeeper` which must be the location for delegation tokens to work across Solr servers (when running in SolrCloud mode). No other option is available at this time.",
          "`solr.kerberos.delegation.token.signer.secret.provider.zookeper.path`",
          "The ZooKeeper path where the secret provider information is stored. This is in the form of the path + /security/token. The path can include the chroot or the chroot can be omitted if you are not using it. This example includes the chroot: `server1:9983,server2:9983,server3:9983/solr/security/token`.",
          "`solr.kerberos.delegation.token.secret.manager.znode.working.path`",
          "The ZooKeeper path where token information is stored. This is in the form of the path + /security/zkdtsm. The path can include the chroot or the chroot can be omitted if you are not using it. This example includes the chroot: `server1:9983,server2:9983,server3:9983/solr/security/zkdtsm`."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#start-solr",
        "fileName":"kerberos-authentication-plugin",
        "title":"Start Solr",
        "anchor":"#start-solr",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Start Solr"],
        "level":2,
        "hasText":true,
        "text":["Once the configuration is complete, you can start Solr with the `bin/solr` script, as in the example below, which is for users in SolrCloud mode only. This example assumes you modified `bin/solr.in.sh` or `bin/solr.in.cmd`, with the proper values, but if you did not, you would pass the system parameters along with the start command. Note you also need to customize the `-z` property as appropriate for the location of your ZooKeeper nodes.",
          "bin/solr -c -z server1:2181,server2:2181,server3:2181/solr",
          "If you have defined `ZK_HOST` in `solr.in.sh`/`solr.in.cmd` (see <<setting-up-an-external-zookeeper-ensemble#updating-solr-include-files,instructions>>) you can omit `-z <zk host string>` from the above command."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#test-the-configuration",
        "fileName":"kerberos-authentication-plugin",
        "title":"Test the Configuration",
        "anchor":"#test-the-configuration",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration",
          "Test the Configuration"],
        "level":2,
        "hasText":true,
        "text":["Do a `kinit` with your username. For example, `kinit \\user@EXAMPLE.COM`.",
          "Try to access Solr using `curl`. You should get a successful response."],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#kerberos-authentication-configuration"},
      {
        "id":"kerberos-authentication-plugin:#kerberos-authentication-configuration",
        "fileName":"kerberos-authentication-plugin",
        "title":"Kerberos Authentication Configuration",
        "anchor":"#kerberos-authentication-configuration",
        "path":["Kerberos Authentication Plugin",
          "Kerberos Authentication Configuration"],
        "level":1,
        "hasText":true,
        "text":["Configuration of the Kerberos plugin has several parts:",
          "Create service principals and keytab files",
          "ZooKeeper configuration",
          "Create or update `/security.json`",
          "Define `jaas-client.conf`",
          "Solr startup parameters",
          "We'll walk through each of these steps below."],
        "childrenCount":"8",
        "_nest_parent_":"kerberos-authentication-plugin"},
      {
        "id":"kerberos-authentication-plugin:#delegation-tokens-with-solrj",
        "fileName":"kerberos-authentication-plugin",
        "title":"Delegation Tokens with SolrJ",
        "anchor":"#delegation-tokens-with-solrj",
        "path":["Kerberos Authentication Plugin",
          "Using SolrJ with a Kerberized Solr",
          "Delegation Tokens with SolrJ"],
        "level":2,
        "hasText":true,
        "text":["Delegation tokens are also supported with SolrJ, in the following ways:",
          "`DelegationTokenRequest` and `DelegationTokenResponse` can be used to get, cancel, and renew delegation tokens.",
          "`HttpSolrClient.Builder` includes a `withKerberosDelegationToken` function for creating an HttpSolrClient that uses a delegation token to authenticate.",
          "Sample code to get a delegation token:",
          "private String getDelegationToken(final String renewer, final String user, HttpSolrClient solrClient) throws Exception {",
          "    DelegationTokenRequest.Get get = new DelegationTokenRequest.Get(renewer) {",
          "      @Override",
          "      public SolrParams getParams() {",
          "        ModifiableSolrParams params = new ModifiableSolrParams(super.getParams());",
          "        params.set(\"user\", user);",
          "        return params;",
          "      }",
          "    };",
          "    DelegationTokenResponse.Get getResponse = get.process(solrClient);",
          "    return getResponse.getDelegationToken();",
          "  }",
          "To create a `HttpSolrClient` that uses delegation tokens:",
          "HttpSolrClient client = new HttpSolrClient.Builder(\"http://localhost:8983/solr\").withKerberosDelegationToken(token).build();",
          "To create a `CloudSolrClient` that uses delegation tokens:",
          "CloudSolrClient client = new CloudSolrClient.Builder(Collections.singletonList(\"localhost:2181\"),Optional.empty())",
          "                .withLBHttpSolrClientBuilder(new LBHttpSolrClient.Builder()",
          "                    .withResponseParser(client.getParser())",
          "                    .withHttpSolrClientBuilder(",
          "                        new HttpSolrClient.Builder()",
          "                            .withKerberosDelegationToken(token)",
          "                    ))",
          "                        .build();"],
        "childrenCount":"0",
        "_nest_parent_":"kerberos-authentication-plugin:#using-solrj-with-a-kerberized-solr"},
      {
        "id":"kerberos-authentication-plugin:#using-solrj-with-a-kerberized-solr",
        "fileName":"kerberos-authentication-plugin",
        "title":"Using SolrJ with a Kerberized Solr",
        "anchor":"#using-solrj-with-a-kerberized-solr",
        "path":["Kerberos Authentication Plugin",
          "Using SolrJ with a Kerberized Solr"],
        "level":1,
        "hasText":true,
        "text":["To use Kerberos authentication in a SolrJ application, you need the following two lines before you create a SolrClient:",
          "System.setProperty(\"java.security.auth.login.config\", \"/home/foo/jaas-client.conf\");",
          "HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());",
          "You need to specify a Kerberos service principal for the client and a corresponding keytab in the JAAS client configuration file above. This principal should be different from the service principal we created for Solr.",
          "Here’s an example:",
          "SolrJClient {",
          "  com.sun.security.auth.module.Krb5LoginModule required",
          "  useKeyTab=true",
          "  keyTab=\"/keytabs/foo.keytab\"",
          "  storeKey=true",
          "  useTicketCache=true",
          "  debug=true",
          "  principal=\"solrclient@EXAMPLE.COM\";",
          "};"],
        "childrenCount":"1",
        "_nest_parent_":"kerberos-authentication-plugin"},
      {
        "id":"kerberos-authentication-plugin",
        "fileName":"kerberos-authentication-plugin",
        "title":"Kerberos Authentication Plugin",
        "isDocumentRoot":true,
        "childrenCount":"5"},
      {
        "id":"about-tokenizers:##DOC",
        "fileName":"about-tokenizers",
        "title":"About Tokenizers",
        "path":["About Tokenizers"],
        "level":0,
        "hasText":false,
        "childrenCount":"0",
        "_nest_parent_":"about-tokenizers"},
      {
        "id":"about-tokenizers:##PREAMBLE",
        "fileName":"about-tokenizers",
        "title":"Preamble",
        "path":["About Tokenizers",
          "Preamble"],
        "level":0,
        "hasText":true,
        "text":["The job of a <<tokenizers.adoc#tokenizers,tokenizer>> is to break up a stream of text into tokens, where each token is (usually) a sub-sequence of the characters in the text. An analyzer is aware of the field it is configured for, but a tokenizer is not. Tokenizers read from a character stream (a Reader) and produce a sequence of Token objects (a TokenStream).",
          "Characters in the input stream may be discarded, such as whitespace or other delimiters. They may also be added to or replaced, such as mapping aliases or abbreviations to normalized forms. A token contains various metadata in addition to its text value, such as the location at which the token occurs in the field. Because a tokenizer may produce tokens that diverge from the input text, you should not assume that the text of the token is the same text that occurs in the field, or that its length is the same as the original text. It's also possible for more than one token to have the same position or refer to the same offset in the original text. Keep this in mind if you use token metadata for things like highlighting search results in the field text.",
          "The class named in the tokenizer element is not the actual tokenizer, but rather a class that implements the `TokenizerFactory` API. This factory class will be called upon to create new tokenizer instances as needed. Objects created by the factory must derive from `Tokenizer`, which indicates that they produce sequences of tokens. If the tokenizer produces tokens that are usable as is, it may be the only component of the analyzer. Otherwise, the tokenizer's output tokens will serve as input to the first filter stage in the pipeline.",
          "A `TypeTokenFilterFactory` is available that creates a `TypeTokenFilter` that filters tokens based on their TypeAttribute, which is set in `factory.getStopTypes`.",
          "For a complete list of the available TokenFilters, see the section <<tokenizers.adoc#tokenizers,Tokenizers>>."],
        "childrenCount":"0",
        "_nest_parent_":"about-tokenizers"},
      {
        "id":"about-tokenizers:#when-to-use-a-charfilter-vs-a-tokenfilter",
        "fileName":"about-tokenizers",
        "title":"When to Use a CharFilter vs. a TokenFilter",
        "anchor":"#when-to-use-a-charfilter-vs-a-tokenfilter",
        "path":["About Tokenizers",
          "When to Use a CharFilter vs. a TokenFilter"],
        "level":1,
        "hasText":true,
        "text":["There are several pairs of CharFilters and TokenFilters that have related (i.e., `MappingCharFilter` and `ASCIIFoldingFilter`) or nearly identical (i.e., `PatternReplaceCharFilterFactory` and `PatternReplaceFilterFactory`) functionality and it may not always be obvious which is the best choice.",
          "The decision about which to use depends largely on which Tokenizer you are using, and whether you need to preprocess the stream of characters.",
          "For example, suppose you have a tokenizer such as `StandardTokenizer` and although you are pretty happy with how it works overall, you want to customize how some specific characters behave. You could modify the rules and re-build your own tokenizer with JFlex, but it might be easier to simply map some of the characters before tokenization with a `CharFilter`."],
        "childrenCount":"0",
        "_nest_parent_":"about-tokenizers"},
      {
        "id":"about-tokenizers",
        "fileName":"about-tokenizers",
        "title":"About Tokenizers",
        "isDocumentRoot":true,
        "childrenCount":"3"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:##DOC",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"RequestHandlers and SearchComponents in SolrConfig",
        "path":["RequestHandlers and SearchComponents in SolrConfig"],
        "level":0,
        "hasText":false,
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:##PREAMBLE",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"Preamble",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Preamble"],
        "level":0,
        "hasText":true,
        "text":["After the `<query>` section of `solrconfig.xml`, request handlers and search components are configured.",
          "A _request handler_ processes requests coming to Solr. These might be query requests or index update requests. You will likely need several of these defined, depending on how you want Solr to handle the various requests you will make.",
          "A _search component_ is a feature of search, such as highlighting or faceting. The search component is defined in `solrconfig.xml` separate from the request handlers, and then registered with a request handler as needed.",
          "These are often referred to as \"requestHandler\" and \"searchComponent\", which is how they are defined in `solrconfig.xml`."],
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:#searchhandlers",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"SearchHandlers",
        "anchor":"#searchhandlers",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Request Handlers",
          "SearchHandlers"],
        "level":2,
        "hasText":true,
        "text":["The primary request handler defined with Solr by default is the \"SearchHandler\", which handles search queries. The request handler is defined, and then a list of defaults for the handler are defined with a `defaults` list.",
          "For example, in the default `solrconfig.xml`, the first request handler defined looks like this:",
          "<requestHandler name=\"/select\" class=\"solr.SearchHandler\">",
          "  <lst name=\"defaults\">",
          "    <str name=\"echoParams\">explicit</str>",
          "    <int name=\"rows\">10</int>",
          "  </lst>",
          "</requestHandler>",
          "This example defines the `rows` parameter, which defines how many search results to return, to \"10\". The `echoParams` parameter defines that the parameters defined in the query should be returned when debug information is returned. Note also that the way the defaults are defined in the list varies if the parameter is a string, an integer, or another type.",
          "All of the parameters described in the section  <<searching.adoc#searching,Searching>> can be defined as defaults for any of the SearchHandlers.",
          "Besides `defaults`, there are other options for the SearchHandler, which are:",
          "`appends`: This allows definition of parameters that are added to the user query. These might be <<common-query-parameters.adoc#fq-filter-query-parameter,filter queries>>, or other query rules that should be added to each query. There is no mechanism in Solr to allow a client to override these additions, so you should be absolutely sure you always want these parameters applied to queries.",
          "`invariants`: This allows definition of parameters that cannot be overridden by a client. The values defined in an `invariants` section will always be used regardless of the values specified by the user, by the client, in `defaults` or in `appends`.",
          "The final section of a request handler definition is `components`, which defines a list of search components that can be used with a request handler. They are only registered with the request handler. How to define a search component is discussed further on in the section on <<Search Components>> below. The `components` element can only be used with a request handler that is a SearchHandler.",
          "The `solrconfig.xml` file includes many other examples of SearchHandlers that can be used or modified as needed."],
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig:#request-handlers"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:#updaterequesthandlers",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"UpdateRequestHandlers",
        "anchor":"#updaterequesthandlers",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Request Handlers",
          "UpdateRequestHandlers"],
        "level":2,
        "hasText":true,
        "text":["The UpdateRequestHandlers are request handlers which process updates to the index.",
          "In this guide, we've covered these handlers in detail in the section <<uploading-data-with-index-handlers.adoc#uploading-data-with-index-handlers,Uploading Data with Index Handlers>>."],
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig:#request-handlers"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:#shardhandlers",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"ShardHandlers",
        "anchor":"#shardhandlers",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Request Handlers",
          "ShardHandlers"],
        "level":2,
        "hasText":true,
        "text":["It is possible to configure a request handler to search across shards of a cluster, used with distributed search. More information about distributed search and how to configure the shardHandler is in the section <<distributed-search-with-index-sharding.adoc#distributed-search-with-index-sharding,Distributed Search with Index Sharding>>."],
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig:#request-handlers"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:#implicit-request-handlers",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"Implicit Request Handlers",
        "anchor":"#implicit-request-handlers",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Request Handlers",
          "Implicit Request Handlers"],
        "level":2,
        "hasText":true,
        "text":["Solr includes many out-of-the-box request handlers that are not configured in `solrconfig.xml`, and so are referred to as \"implicit\" - see <<implicit-requesthandlers.adoc#implicit-requesthandlers,Implicit RequestHandlers>>."],
        "childrenCount":"0",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig:#request-handlers"},
      {
        "id":"requesthandlers-and-searchcomponents-in-solrconfig:#request-handlers",
        "fileName":"requesthandlers-and-searchcomponents-in-solrconfig",
        "title":"Request Handlers",
        "anchor":"#request-handlers",
        "path":["RequestHandlers and SearchComponents in SolrConfig",
          "Request Handlers"],
        "level":1,
        "hasText":true,
        "text":["Every request handler is defined with a name and a class. The name of the request handler is referenced with the request to Solr, typically as a path. For example, if Solr is installed at `\\http://localhost:8983/solr/` and you have a collection named \"gettingstarted\", you can make a request that looks like this:",
          "http://localhost:8983/solr/gettingstarted/select?q=solr",
          "This query will be processed by the request handler with the name `/select`. We've only used the \"q\" parameter here, which includes our query term, a simple keyword of \"solr\". If the request handler has more parameters defined, those will be used with any query we send to this request handler unless they are over-ridden by the client (or user) in the query itself.",
          "If you have another request handler defined, you would send your request with that name. For example, `/update` is a request handler that handles index updates (i.e., sending new documents to the index). By default, `/select` is a request handler that handles query requests.",
          "Request handlers can also process requests for nested paths of their names, for example, a request using `/myhandler/extrapath` may be processed by a request handler registered with the name `/myhandler`. If a request handler is explicitly defined by the name `/myhandler/extrapath`, that would take precedence over the nested path. This assumes you are using the request handler classes included with Solr; if you create your own request handler, you should make sure it includes the ability to handle nested paths if you want to use them with your custom request handler.",
          "It is also possible to configure defaults for request handlers with a section called `initParams`. These defaults can be used when you want to have common properties that will be used by each separate handler. For example, if you intend to create several request handlers that will all request the same list of fields in the response, you can configure an `initParams` section with your list of fields. For more information about `initParams`, see the section <<initparams-in-solrconfig.adoc#initparams-in-solrconfig,InitParams in SolrConfig>>."],
        "childrenCount":"4",
        "_nest_parent_":"requesthandlers-and-searchcomponents-in-solrconfig"}]
  }}