Domain Masking with Proxy Server Integration

Introduction

Whatfix fetches and displays content in your application through API calls to the Whatfix Content Delivery Network (CDN). Many organizations implement strict Content Security Policies (CSPs) that block external domains by default, hindering these API calls. To enable Whatfix content to function within your application, update your CSP to include the necessary Whatfix domains.

Modifying CSPs in large enterprises proves complex and time-consuming, often requiring multiple reviews and approvals, which complicates the integration of every service.

To simplify this process, Whatfix offers a solution called domain masking. This feature uses a proxy server to handle end-user API requests, eliminating direct references to Whatfix domains. This approach enables maintenance of brand identity, provision of a consistent user experience, and implementation of security measures on the proxy server without modifying your CSP for Whatfix domains.

Note:

• To set up this integration, contact support@whatfix.com.

• This integration must be setup by your organization’s IT team.

Here’s how the integration works.
Consider a user who needs help on an application where Whatfix is deployed. The user launches Self Help for assistance and this normally sends a message directly to Whatfix. However, with this new proxy server integration, that message first goes to a dedicated server, similar to a mailroom. The mailroom has several important functions:

1. The mailroom (proxy server) reads the API request from the end user, replaces the request with the Whatfix domain, and then forwards the request to Whatfix.

2. The proxy server can implement additional security protocols, such as authentication and authorization checks, before forwarding the request to Whatfix. On receiving the request, Whatfix processes it and transmits the relevant information back to the mailroom.

3. Finally, the mailroom server delivers the answer to the user on the website, ensuring everything appears consistent with the brand.

This architecture provides a secure, branded, and controlled integration with Whatfix, shielding end users from any direct interaction with the third-party service.

The following GIF illustrates the data requests between end users, proxy server, and Whatfix:

Why use a Proxy Server?

Proxy Server provides crucial security, control, branding consistency, and helps overcome technical limitations. Here are the benefits of using a proxy server:

• Improved Security and Monitoring: You might need to keep a close eye on all the data going in and out. The Proxy Server enables you to:

  • Inspect Contents: Check exactly what information is being sent.

  • Store Logs: Keep records of all the requests and data.

  • Filter Content by Security: Block or change certain types of information for security reasons.

• Maintain Domain Consistency: All the requests appear to come from your own website, keeping everything consistent and professional with your branding guidelines.

• Route Network Restrictions: If your organization enforces strict firewalls and block connections to certain websites or services, a Proxy Server on your own domain, can bypass restrictions.

• Protect Sensitive Data: You may want to be extra careful about sensitive information, like user names or personal details. The Proxy Server adds a layer of protection by preventing this data from being directly sent to a third-party domain.

<script language='javascript' async='true' type='text/javascript' 
src='https://xyz-whatfix.xyz.com/prod/{ent_id}/initiator/initiator.nocache.js'></script>

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /etc/ssl/certs/nginx-xyz-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-xyz-selfsigned.key;

	server_name xyz-whatfix.xyz.com;

    #Route all static files to Whatfix CDN
    location /prod/ {
        proxy_buffering off;
        proxy_ssl_server_name on;
        proxy_pass https://cdn.whatfix.com/prod/;
    }
    
	#Route all other patterns to Whatfix API Servers
    location / {
        proxy_buffering off;
        proxy_ssl_server_name on;
        proxy_pass https://whatfix.com;
    }
}

sudo nginx -s reload