Minimum Requirements for a Bright Integration
Bright can mostly work out of Javascript served to the page, but it requires some minimal information provided by the web stack.
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?].
Since Bright functionality is exposed to the end page via bright.js, our javascript library requires the webstack obtain an API key from the Bright API, and stuff it into the page. This can be a simple meta tag like:
<meta name='bright-token' content='d6b6572b1bef282209d944f8d77d5992'/>
The API key can be acquired by calling the Bright RESTful API at this endpoint:
https://github.com/bretweinraub/bright-api-doc/blob/master/v2_api_controller.md#sec-5-1-1
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.
Rationale
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' content='support@aura-software.com'/>
Including all the fields above will mean that the page won't have to fetch this data from when bright.js initializes.
Caching
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.