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
Updated almost 4 years ago