On-Premises Deployment Technical Notes

Diagram of the On-Premises Deployment

On-Premises Key Notes

Code Information	JavaScript, HTML and CSS Library of files hosted by client. Configuration JSON file, hosted by ForeSee, is requested on the first page load and moved to browser storage for remainder of visit.
Cookie Information	One first-party persistent cookie (encrypted and compressed) hosted under the site domain (clientsite.com). No third-party cookies required unless you put the Web SDK in a domain other than the main HTML page.
Network Calls to Foresee	One call per visit to Health.foresee.com to ensure services are running prior to the invitation being displayed. One call per visit to ForeSee Content Publishing server to pull down a JSON file containing configurations for Survey, Feedback, and Replay. JSON files are parsed (not executed) by the browser using native parsing capabilities. Network connections are secured with SSL. JSON files are produced by our publishing system, which is secured by various means and has both at-rest and end-to-end in-motion encryption.
Survey Presentation and Submission	ForeSee hosts the survey questionnaire and the respondent data.
Code Version Updates	Maintained by the client.

App Server Requirements

The client code is entirely browser side, but there are some nuances that could affect your deployment depending on how you have your app server configured.

URL Length Limits

Most modern web servers have an enforced URL length limit of 8 kilobytes (KB). Foresee's Feedback product can (on occasion) produce URL's as long as 2KB or 3KB when loading our survey, depending on how many CPPs have been set for the session. This normally is not a problem, but if the server that is serving up the fs.feedbacksurvey.html file is enforcing a 2KB limit, then you might occasionally trigger a server error for the user with Feedback.

Another option for setting CPPs is to use the CPP API. This can be helpful if URL length limits do not allow setting of certain CPPs in the URL.

Security Headers

If you are serving the ForeSee files from the same domain or origin as your primary website, then implementing any security headers (specifically the X-FRAME-OPTIONS or Content Security Policy) isn't expected to be an issue.

If, however, you are serving the files from a different domain, you must pay attention to what headers are being set for the ForeSee files. For example: if your website is hosted at http://www.retailwebsite.com but your ForeSee files are hosted at http://retailwebsitecdn.com then you must pay attention to these headers. Specifically, avoid any X-Frame-Options settings that disallow cross-domain communication. For example:

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

You can still have an X-Frame-Options header if you whitelist your own domains using ALLOW-FROM. See [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] for more information.

The other problematic header is the Content Security Policy (X-Content-Security-Policy). This can also be set with a <meta /> tag. If you're using a CSP, you must whitelist your own domain for cross-site-scripting and for loading of iFrames. A blanket policy that should make requests from your website safe might look like:

Content-Security-Policy: default-src 'self' *.retailwebsite.com