Typically, this looks like this:
Who Are You?
The webstack receives the HTTP requests from the browser, and part of those are the cookies associated with the user’s session. This means the webstack knows “who” is accessing the page [or is it an anonymous user?].
<meta name='bright-token' content='d6b6572b1bef282209d944f8d77d5992'/>
The API key can be acquired by calling the Bright RESTful API at this endpoint:
Then just take the access token out of the response, place it into a meta tag, load the bright.js through normal script tags, and you should be good to go.
The API Key gives the user access to certain Bright API calls, for a limited duration. If someone highjacked your session [via MITM attack or otherwise], the amount of havoc they could wreak is limited by the token expiration time. If you put the token expiration time into the page, bright.js can do some intelligent things with that information but it’s not critical. For example
<meta name='bright-token-expiration' content='2016-12-13T03:41:42.731Z'/>
Recommended amount of data to send to the page.
For various historical reasons, we typically wrote the following to the page:
<meta name='bright-token' content='somesortoflongSHA'/> <meta name='bright-token-expiration' content='2016-12-13T03:41:42.731Z'/> <meta name='bright-api-url' content='https://[bright-api-url]/bright/api/v2'/> <meta name='bright-first-name' content='My'/> <meta name='bright-last-name' content='LastName'/> <meta name='bright-email' firstname.lastname@example.org'/>
Including all the fields above will mean that the page won’t have to fetch this data from when bright.js initializes.
Current webstack implementations for Bright, like WordPress and Drupal, cache the API key along with the expiration date and return the cached key to the page if it hasn’t expired. This can save time and improve page performance.