FIREFLY ARCHITECTURE: CO-BROWSING AT SCALE FOR THE ENTERPRISE

Transcription

1 FIREFLY ARCHITECTURE: CO-BROWSING AT SCALE FOR THE ENTERPRISE Table of Contents Introduction... 2 Architecture Overview... 2 Supported Browser Versions and Technologies... 3 Firewalls and Login Sessions... 3 Hosted vs. On-Premise... 4 Data Security and Privacy... 4 API Access... 4 Conclusion... 5 Abstract This document details the technical architecture of Firefly. It covers the backend infrastructure, serverclient connection methods, software delivery methods, API access details, security, reliability, and more. Product Information: Sales Inquiries: product@usefirefly.com sales@usefirefly.com (213) Address: 3720 Spruce Street #212 Philadelphia, PA Copyright 2013 North, Inc. Page 1

2 Introduction Firefly is a lightweight but powerful co-browsing application that allows an agent to view a single tab of a customer s browser in real-time. The product does not require any downloads, installations, Flash, or Java for either the viewer or presenter. It runs entirely on JavaScript within the web browser, is secure and reliable, and transmits page updates instantly. Firefly runs in the cloud on Amazon Web Services (AWS) using Elastic Cloud Compute (EC2) for server processing and Elastic Block Store for permanent data storage. The architecture autoscales past multiple EC2 instances to meet variable load demand and ensures automatic failover at each point of the data flow journey in order to provide a guaranteed >99.99% uptime. Architecture Overview A Firefly co-browsing session involves the following flow: 1. A presenter initiates a session from their web browser. 2. The presenter s browser establishes a persistent connection with the application server. 3. The presenter requests a unique session code that is generated by the database and returned to the presenter. 4. A viewer enters the session code from the dashboard on their account or visits the appropriate URL. 5. The viewer s browser establishes a persistent connection with the application server. 6. The server checks to ensure the existence of a session connected to the entered session code. 7. If such a session exists, the server requests the initial state of the web page from the presenter browser and relays it to the viewer. 8. The presenter is notified of the viewer s connection. 9. The presenter s browser listens for page updates and relays them instantly to the viewer through our application server. Firefly s server architecture is hosted on Amazon Web Services. The service employs high-cpu Elastic Cloud Compute instances, and the architecture is scalable to multiple app and database instances through real-time server provisioning. Multiple application servers sit behind several HAProxy load balancers to efficiently distribute load and ensure automatic failover in the case of a server outage. Application servers utilize dedicated Redis instances for publish/subscribe functionality to maintain state across multiple server instances. This configuration enables a customer s client and an agent s client to connect to two separate servers, despite connecting to the same session. Redis serves as the backend bridge between servers, playing a critical role in the relaying of data between multiple clients in a cobrowsing session. This setup grants the load balancer the most flexibility in distributing client requests to application servers. The primary database resides in Amazon s Elastic Block Store and therefore lives independently from the life of the database server. The database is in a RAID 10 configuration for improved throughput via blocklevel data striping as well as protection from faulty hardware via data mirroring. Redis and our primary database are both configured with master-slave replication. This setup provides scalability for database reads and for publishing to data subscriptions. It also provides a source from which to continuously create database snapshots to ensure the safety of our data. All types of server instances (load balancers, application servers, primary database, Redis) are distributed evenly across AWS Availability Zones for protection against a single datacenter failure. Databases are in a master-slave configuration for multiple availability at the Slave level. All servers are continuously Copyright 2013 North, Inc. Page 2

3 monitored to ensure uptime, and should a server be detected as being down, a new server is automatically spun up. At the event of a Master database failure, a Slave is promoted to Master, and a new Slave database is subsequently provisioned. In the case of a server outage or code deployment for a particular application server, all sessions in progress are appropriately maintained with zero downtime. Clients connected to the unavailable server are notified of the disconnection and automatically reconnect to an available application server via the load balancer. Clients maintain the session code in memory and bind to this session code on the server, ensuring the connection between the presenter and viewer is maintained. There will be a brief pause in the session, but the session resumes in a matter of milliseconds. Firefly s deployment process relies on rolling deployment to ensure the availability of a minimum number of servers at any given time. Application instances rely on Node.js to handle server requests and responses and to communicate with the database. The open source Socket.io library is used to facilitate persistent connections between the server and client. The library uses WebSockets when natively supported in browsers and falls back to JSONP polling in the case that WebSockets are not supported. The application architecture is currently being modified to allow fallback to Flash Sockets before resorting to the JSONP polling transport. Firefly s JavaScript library must be loaded into every web page where co-browsing is desired. This file is about 205KB in size at the time of the publication of this document and is loaded into the page asynchronously so as not to block the loading of any other HTML content. The library does not leak any global variables onto the window namespace to remove any risk of variable conflict, except for the FireflyAPI object that is used to scope Firefly s JavaScript API. Supported Browser Versions and Technologies It does not make a difference if the presenter is using a different browser from that of the viewer. We support the following browsers on both the agent and customer side: All Chrome versions All Firefox versions All Safari versions Internet Explorer 8 and above IE7 support is on the 2013 roadmap (but can be prioritized based on customer needs) The following browser technologies are supported: Standard DOM nodes and any JavaScript permutations to these DOM nodes Same-domain iframes and any JavaScript permutations inside these iframes The initial state of a cross-domain iframe HTML5 Canvas and updates to a Canvas element Doctypes Images Firewalls and Login Sessions Firefly works seamlessly behind all firewalls and login walls. The JavaScript library communicates via port 80 for unencrypted requests and port 443 for encrypted requests. Copyright 2013 North, Inc. Page 3

4 Hosted vs. On-Premise Hosted Delivery Firefly s hosted version provides co-browsing functionality without the need to host code on your own servers. Integration is as simple as pasting and deploying a snippet of JavaScript code provided by Firefly into every page where co-browsing is desired. A web page must have the Firefly JavaScript library to enable co-browsing, and it is recommended to place the snippet of code as high up in the HEAD tag as possible. The agent dashboard from which the agent connects to a session is accessed via an account on the usefirefly.com domain. On-Premise Delivery Firefly also offers an on-premise solution for those that would like to bring Firefly in-house. The solution is set up by running bash scripts provided by Firefly for the application server and the database server. These scripts fetch and build any required open source libraries as well as Firefly s custom server-side code libraries. Additionally, Firefly provides the client-side JavaScript files that are modified to point to a domain and use custom logo assets. Data Security and Privacy All communications, either between the customer and the server or between the agent and the server, are encrypted via 256-bit SSL. The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and RSA as the key exchange mechanism. Limited session information and zero HTML data is stored in the database. Data stored includes Timestamps for sessions URL s of the pages that the session was conducted on User agent string of the customer User agent string of the rep The session code All of this information is saved either for analytics reporting or for internal debugging. Firefly has the ability to detect HTML elements that are marked as sensitive so that this information never touches the application servers nor does the agent ever see this information. To mark an element as sensitive, add an HTML class of firefly-sensitive-data to the element. This feature works with any DOM node, including form inputs and textareas. API Access Firefly exposes 4 main APIs: the JavaScript API, the Event API, the Form Masking API, and the RESTful HTTP API. JavaScript API The JavaScript API can be used to initiate a co-browsing session from inside of your application. Many of our customers use this API to activate Firefly from inside of a chat application, inside of a click-to call application, or from a custom drop down. When called, the Firefly API generates a URL that allows an agent to connect to the session and view the customer s browser tab. It can also be used to set various other options, including styling themes and a custom pop-up message for the customer. For more information and documentation, please visit our online API documentation: Copyright 2013 North, Inc. Page 4

5 Event API Firefly s Event API allows your application to hook into events in the Firefly cobrowsing lifecycle. This API allows your application to subscribe to events and receive notifications in real-time when actions occurs, such as when the customer or agent leaves the call or when the call ends. For more information and documentation, please reach out and request our white paper Firefly API Documentation: Event and Form Masking API. Form Masking API Firefly s Masking API allows you to redact sensitive elements and form fields on the customer s page. Content in redacted elements and forms will never be transported to our servers and will never reach the agent s browser, enabling you and your clients to maintain PCI and HIPPA compliance. This API works by adding a specific CSS class selector to all sensitive elements or calling the Masking API. For more information and documentation, please reach out and request our white paper Firefly API Documentation: Event and Form Masking API. RESTful HTTP API The RESTful HTTP API exposes access to permanently stored information about past cobrowsing sessions in a JSON format. This information includes the session code, the browser of the customer, the session duration, the pages on which the session traversed, and more. For more information and documentation, please reach out and request our white paper Firefly API Documentation: RESTful HTTP API. Conclusion Firefly s architecture is robust, reliable, secure and scalable. It is very well suited for even the most privacy and security conscious organizations and can be trusted to handle the co-browsing activities of the largest organizations in the world. For technical inquiries, please contact product@usefirefly.com For sales inquiries, please contact sales@usefirefly.com Copyright 2013 North, Inc. Page 5