Step 3: Configure Your Search Experience

Prerequisites

If you are using a Jambo Template, you’ll need to update the structure of your config from legacy to our new Sites structure (part of Developer Preview). This will enable you to use tokens in your Site. Follow the steps here to make the necessary changes.

Visitor OPT-In

Note that ALL visitor level analytics are opt-in. That means, anything calling the visitor attribute can be omitted if you would NOT like to track this data. Read more about this here in the next step of the guide.

Step 1: Pass the Token to Search

Next, you’ll need to make sure that Search can accept the token you have minted. You’ll need to make the following changes to your repo, depending on if your Search experience is hosted with Core or Headless, or is living on a subdomain or an iFrame. You can refer to hitchhikers for more information between a subdomain here and iFraming here .

Tip

NOTE: Make sure you are on version 1.27 of Theme or later.

Option 1 (Recommended): Core or Headless

In provideCore, mint a token and pass it in place of the apiKey, and pass the visitor attribute from the Yext Auth object

import { provideCore } from '@yext/search-core';
const core = provideCore({
 token: '<jwt>',
 vistor: '<visitorId>', //OPT_IN FEATURE
 //etc
})

Option 2: Subdomain

1. In your global_config.json, set useJWT and initializeManually to true.
2. In the on_document_load partial, add the call for the runtime config with the tokenHeader attribute, and pass the visitor if you are using visitor analytics.

In order to add the on_document_load partial in Jambo, click Tools>Override Theme>script>on-document-load.js>Submit.

Since you are redirecting to this subdomain, you will need to store the token and visitor in local storage or in a url param, for the subdomain to use.

var token = this.localStorage?.myToken; // store the token in local storage
var token = this.window.hrefsomething; //store the token in a url param
var visitor = this.localStorage?.visitor; // store the token in local storage
var visitor = this.window.hrefsomething; //store the token in a url param

AnswersExperience.runtimeConfig.set('tokenHeader', token);

 	AnswersExperience.runtimeConfig.set('visitor', visitor);

	AnswersExperience.init()

Option 3: JS Snippet (iFraming)

The following steps will be very similar to Using JWT with Search . In addition to those steps:

1. In your global_config.json, set initializeManually and useJWT to true.
2. (Recommended) The domain for Search should be a subdomain of the parent domain, so that you can access things on the parent window from the iframe. This will likely make your life easier.

3. Call the following from the outer page

   AnswersExperienceFrame.init({
   "visitor": '<visitorId>', //OPT_IN FEATURE
   "tokenHeader": '<jwt>'
   }). 
   

Security Call Out

The JS Snippet option is creating an iframe that pulls in the Search page. While that page is technically still accessible (you could inspect it and pull off the iframe src), the page itself will not load the Search experience unless a JWT is provided and the init function is called. The page itself is not gated by authentication..

UX Call Out

If you’re using the JS Snippet option and have CTAs that click out to entity pages hosted on sites, your users will be redirected through an authentication flow. They should not need to log in again, but since Sites is on a separate domain, this authentication is necessary.

Step 2: Configure Search Bar

Next, you’ll need to configure the search bar on your website linking to your Search experience. There are two different search bar options which you can read more about here . The configuration of the search bar with Authorized Search changes in that you must pass in the token rather than API Key, in addition to now passing the visitor object if you are using visitor analytics (see the ‘Visitor Analytics’ step of this guide for more information).

Make the following changes when you initialize Search:

1. Replace apiKey with token.
2. Add visitor attribute (OPT_IN).

So, your search bar initialization will look something like the following:

ANSWERS.init({
token: '<jwt>'
visitor: '<visitorId>', 
//etc
ANSWERS.addComponent(‘searchbar’, { .. });

});

Step 3: Edit Search Configuration

Finally, you’ll need to configure the verticals in your Search experience that you would like to use Authorized search. If using Yext Auth, you need to set the type to yext in the JSON config. You can do this by navigating to your Search experience, clicking Edit in Json on the left, and adding in this snippet of code for the vertical you intend to protect with Yext Auth permissions. Note that this is done on the vertical level.

If you are interested in using External Authorization as well, see the ‘Use External Authorization on Yext Users for Search’ step of this guide.

{
  "verticals": {
    "googleDrive": {
      "entityTypes": ["googleDriveDocument"],
      "authorization": {
			"type": "yext"
		}
      },

Query Suggest / Spell Check

Currently, Query Suggest and Spellcheck are not compatible with Authorized Search. This means that entities that may not surface as an answers result DO still exist as part of Query Suggest and Spellcheck. We therefore recommend TURNING OFF those two features in order to make sure your experience is extremely secure.