Requests may be allowed or blocked based on referrer. A referrer identifies the URL for the web page from which the link was followed. The two parameters that leverage referrer information are identified below.
| Parameter | Description |
|---|---|
|
ec_ref_allow |
Only requests that match the specified referrer will be allowed. |
|
ec_ref_deny |
Only requests that match the specified referrer will be denied. |
Key information:
When specifying multiple referrers, make sure that you do not add a space along with the comma delimiter. Referrers that are preceded by a space will be ignored.
A single asterisk (*) may be used as a wildcard at the beginning of the assigned parameter value. Parameters configured in this way will match zero or more characters for the subdomain portion of the URL (e.g., secure in secure.domain.com). A wildcard will not match forward slashes (/), nor can it be used to match characters in other portions of the URL.
Some browsers can be configured to not send referrer information. By default, the ec_ref_allow parameter will block these requests, since they do not match the specified criteria. Likewise, the default behavior of ec_ref_deny is to allow these requests. If you would like to change the default way in which blank or missing referrers are handled, then you should assign either a "Missing" or a blank value to the desired parameter.
All of the following sample values will grant access for requests with blank or missing referrers.
The trailing comma in the second example allows blank or missing referrers.
All of the following sample values will deny access for requests with blank or missing referrers.
We will now use a sample URL to demonstrate how access will be granted or denied based on tokens that take advantage of the ec_ref_allow parameter. The following scenario assumes that the token used to request access has the following requirement:
The following table describes how sample requests with the specified referrer will be handled for this scenario.
| Sample Referrer | Authorized? |
|---|---|
|
http:// www.server1.com/Folder1/movie1.htm |
Allowed |
|
http:// www.server1.com/Folder1/movie1.html |
Allowed |
|
http:// www.server1.com/Folder1/movie1/index.htm |
Allowed |
|
https:// data.server1.com/Folder2/movie123.html |
Allowed |
|
https://secure.server2.com/index.html |
Allowed |
|
https://en.secure.server2.com/index.html |
Allowed |
|
[Blank or not provided] |
Denied |
|
http://www.server1.com/ |
Denied |
|
http:// secure.server1.com/Folder1/movie1.htm |
Denied |
|
http://server2.com/index.html |
Denied |
|
http://domain.com/secure.server2.com/index.html |
Denied |
The ec_ref_deny parameter works in the same way. The following scenario assumes that the token used to request access has the following requirement:
The following table describes how sample requests with the specified referrer will be handled for this scenario.
| Sample Referrer | Authorized? |
|---|---|
|
[Blank or not provided] |
Allowed |
|
http://domain.com/secure.server2.com/index.html |
Allowed |
|
http:// www.server1.com/Folder1/movie1.html |
Denied |
|
http:// www.server1.com/Folder1/movie1/index.htm |
Denied |
|
https:// data.server1.com/Folder2/movie123.html |
Denied |
|
https://secure.server2.com/index.html |
Denied |
|
https://en.secure.server2.com/index.html |
Denied |
Edgecast CDN