Restricting Access by Host

Applies To:

HTTP LargeThis platform has been optimized to cache and deliver static content (e.g., HTML, CSS, JavaScript, ISO, multimedia, and software downloads, etc.) over HTTP or HTTPS.

HTTP SmallLegacy. If you are currently serving traffic over this platform, then you may continue to do so. However, we recommend that you serve your traffic over our more robust HTTP Large platform.

ADNThe Application Delivery Network platform has been optimized to deliver dynamic content (e.g., login credentials, account information, etc.) over HTTP or HTTPS. Typically, user-specific and database-driven content are served over this platform.

TBAThe Token-Based Authentication feature enforces authentication prior to content delivery. Authentication takes place via an encoded token value that must be included in the request URL. This token value is then decrypted on an edge server. The requested content will only be delivered when the user meets the requirement(s) defined in the token.

Users may be allowed or blocked based on the host requesting protected content. A host, which is reported by the Host request header field, identifies the hostname of the server from which the content was requested.

Parameter	Description
ec_host_allow	Allows requests to the specified hosts.
ec_host_deny	Denies requests to the specified hosts.

These parameters are not available from within the Encrypt Tool section of the Token Auth page. However, an encrypted token value may still be generated through the Token Generator application or by creating a custom token generator.

Key information:

Do not include the protocol (e.g., http://) or the port number (e.g., :100) associated with the desired host.
- Although the Host request header field will include port information when a non-default port (e.g., www.domain.com:100) is used, it is ignored by this parameter. This parameter performs comparisons on the hostname without port information.
Validate multiple hosts within a single parameter by separating each one with a comma.
- Do not append a space to the comma delimiter. Hostnames that are preceded by a space will be ignored.
Although a typical configuration should not include both parameters, it is possible for a token to contain both of these parameters. In such a case, the ec_host_allow parameter takes precedence over the ec_host_deny parameter.

Wildcard Matching for Subdomains

A wildcard domain may be specified using this syntax: *.Domain. This type of configuration will match any host that contains the specified domain (e.g., www.domain.com, secure.domain.com, and videos.domain.com).

The asterisk (*) character only acts as a wildcard character when it occurs as the first character in the specified hostname.

Allow/Deny Host Examples

We will now use a sample URL to demonstrate how content delivery is affected by tokens that take advantage of the ec_host_allow parameter. In this scenario, a token was generated from the following parameter:

ec_host_allow=www.server1.com,data.server1.com,*.server2.com

The following table describes how sample requests that point to the specified sample host will be handled for this scenario.

Sample Host	Authorized?
www.server1.com	Allowed
data.server1.com	Allowed
secure.server2.com	Allowed
en.secure.server2.com	Allowed
secure.server1.com	Denied
server2.com	Denied

The ec_host_deny parameter works in the same way. In this scenario, a token was generated from the following parameter:

ec_host_deny=www.server1.com,data.server1.com,*.server2.com

The following table describes how sample requests that point to the specified sample host will be handled for this scenario.

Sample Host	Authorized?
secure.server1.com	Allowed
server2.com	Allowed
www.server1.com	Denied
data.server1.com	Denied
secure.server2.com	Denied
en.secure.server2.com	Denied