One first-party persistent cookie (encrypted and compressed) hosted under the site domain (clientsite.com).
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.
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.
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.
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:
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 over 3 years ago