⚠️ Caution: The following article assumes technical knowledge of web servers and related concepts and terminology.
In most organizations, the person who can perform the steps described in this article will be a web administrator (or similar).
This guide also assumes that you have reverse proxy capability available and set up on your website.
Before you get started
Before you get started
We don't require any specific type of reverse proxy, so you can choose the most appropriate option for your situation based on your preference or what you already have in place. The possible options include:
A Content Delivery Network (CDN), e.g. Amazon CloudFront, Akamai, Cloudflare (Enterprise), Limelight, etc.
A dedicated load balancer or reverse proxy server, e.g. HAProxy or NGINX.
A reverse proxy/gateway module on your web server, e.g. mod_proxy on Apache HTTP Server or Application Request Routing on Microsoft IIS.
No matter which option you go with, your specific reverse proxy must support the following functionality to be used with StoryChief:
Proxy requests for a subdirectory and anything below it (e.g. http://www.mycompany.com/blog/*) to a specific origin server.
Proxy GET, HEAD and OPTIONS requests (at minimum these types required; others do not have to be excluded).
Disable caching of the origin server (for CDNs).
Modify headers to the origin request
Start configuring the reverse proxy
Configure the Reverse Proxy
As the exact steps needed to configure your reverse proxy will vary depending on the type of reverse proxy you are using, we're not able to provide detailed, step-by-step instructions on how to do this. Instead, we will describe the general setup objectives you need to achieve, as well as the reasoning behind them, alongside of an example configuration for AWS Cloudfront, an example configuration for Cloudflare and an example configuration for NGINX.
The reverse proxy technology you are using will have its own documentation that outlines the exact steps you need to follow to get the desired result. Use the objectives below to guide you as you configure the settings for your particular reverse proxy.
Objective 1: Proxy Requests for a Subdirectory to a Specific Origin Server
What you need to do:
Create a rule in your reverse proxy. The rule must apply to any request that involves a specific subdirectory on your root domain (including any further subdirectories nested under the designated subdirectory) and pass all requests that meet this criterion to a specific origin server
The subdirectory that will form the basis of the rule can be chosen by yourself (e.g. https://mycompany.com/blog/). It should be communicated with your StoryChief Customer Success Manager so the necessary configuration can be done on our end.
Specify the following origin server: https://mycompany.storychief.io
Why you need to do it:
The underlying goal is to make your William blog accessible under a subdirectory on your website's root domain
William blogs are actually hosted on StoryChief's servers, accessible via the URL https://mycompany.storychief.io/
To serve a blog when a visitor requests the specified subdirectory, you need to identify those requests and automatically send them to https://mycompany.storychief.io/
Objective 2: Ensure the Required Request Methods are Passed
What you need to do:
Your rule must be able to pass all requests that use the following methods:
GET, HEAD, OPTION
Why you need to do it:
To ensure full blog functionality, at minimum Uberflip needs to receive any and all requests that use the 3 methods ("verbs") listed above
Therefore, your reverse proxy must be capable of passing these types of requests without omitting/filtering any
Requests using any other method can also be passed safely.
Objective 3: Ensure Requests are passed correctly to the origin
What you need to do:
Your reverse proxy and/or your rule must be set up in such a way that requests passed to the StoryChief origin server are passed through as-is, with the exception of the Path and Host
The Host header should be the one of the origin, not the one the client inputted. eg. https://mycompany.storychief.io
The path sent over to the origin server should be omitted from the prefix you chose to add. eg: /blog
An additional header should be added for
"X-Referrer": "StoryChief". This allows StoryChief to identify a reversed proxied domain.
Why you need to do it:
For StoryChief to correctly map the request to the actual resource, we expect the incoming URL to be: https://mycompany.storychief.io/my-awesome-article instead of the URL inputted by the client (eg: https://mycompany.com/blog/my-awesome-article)
Objective 4: Enable TLS ("SSL") Between Your Reverse Proxy and the Origin Server
What you need to do:
Requests passed from the reverse proxy server to the origin server must use a secure connection (HTTPS over TLS)
This specifically refers to the connection between the proxy server and the origin server only, i.e. it is a requirement even if your website does not use HTTPS
Why you need to do it:
The StoryChief origin server (https://mycompany.storychief.io) is configured to require HTTPS, so the connection to the reverse proxy should be set to use it
Objective 5: Disable Caching of the Origin Server (If Needed)
What you need to do:
Your reverse proxy may support caching of origin servers (i.e. if you are using a CDN)
If so, you must specifically disable this feature for the StoryChief origin server
Why you need to do it:
If caching is enabled, the proxy server will serve requests from its own cache of the origin server
When a request is served from cache, the request is never passed to the origin server, so StoryChief does not receive the request headers requires to produce metrics.
When a request is served from cache, you might see older blog results on the main page.