标签：
The following set of modules provides extra functionality that will help you find out more information about the visitors, such as by parsing client request headers for browser name and version, assigning an identifier to requests presenting similarities, and so on.
The Browser module parses the User-Agent HTTP header of the client request in order to establish values for variables that can be employed later in the configuration. The three variables produced are:
To help Nginx recognize web browsers, telling the old from the modern, you need to insert multiple occurrences of the ancient_browser and modern_browser directives:
modern_browser opera 10.0;
With this example, if the User-Agent HTTP header contains Opera 10.0, the client browser is considered modern.
Just like the Browser module, the Map module allows you to create maps of values depending on a variable:
map $uri $variable {
/page.html 0;
/contact.html 1;
/index.html 2;
default 0;
}
rewrite ^ /index.php?page=$variable;
Note that the map directive can only be inserted within the http block. Following this example, $variable may have three different values. If $uri was set to /page.html, $variable is now defined as 0; if $uri was set to /contact.html, $variable is now 1; if $uri was set to /index.html, $variable now equals 2. For all other cases (default), $variable is set to 0. The last instruction rewrites the URL accordingly. Apart from default, the map directive accepts another special keyword: hostnames. It allows you to match hostnames using wildcards such as *.domain.com.
Two additional directives allow you to tweak the way Nginx manages the mechanism in memory:
Regular expressions may also be used in patterns if you prefix them with ~ (case sensitive) or ~* (case insensitive):
map $http_referer $ref {
~google "Google";
~* yahoo "Yahoo";
\~bing "Bing"; # not a regular expression due to the \ before the tilde
default $http_referer; # variables may be used
}
The purpose of this module is to provide functionality that is quite similar to the map directive — affecting a variable based on client data (in this case, the IP address). The syntax is slightly different in the extent that you are allowed to specify address ranges (in CIDR format):
geo $variable {
default unknown;
127.0.0.1 local;
123.12.3.0/24 uk;
92.43.0.0/16 fr;
}
Note that the above block is being presented to you just for the sake of the example and does not actually detect U.K. and French visitors; you‘ll want to use the GeoIP module if you wish to achieve proper geographical location detection. In this block, you may insert a number of directives that are specific to this module:
Although the name suggests some similarities with the previous one, this optional module provides accurate geographical information about your visitors by making use of the MaxMind (www.maxmind.com) GeoIP binary databases. You need to download the database files from the MaxMind website and place them in your Nginx directory.
This module is not included in the default Nginx build.
All you have to do then is specify the database path with either directive:
geoip_country country.dat; # country information db
geoip_city city.dat; # city information db
geoip_org geoiporg.dat; # ISP/organization db
The first directive enables several variables: $geoip_country_code (two-letter country code), $geoip_country_code3 (three-letter country code), and $geoip_country_name (full country name). The second directive includes the same variables but provides additional information: $geoip_region, $geoip_city, $geoip_postal_code, $geoip_city_continent_code, $geoip_latitude, $geoip_longitude, $geoip_dma_code, $geoip_area_code, $geoip_region_name. The third directive offers information about the organization or ISP that owns the specified IP address, by filling up the $geoip_org variable.
If you need the variables to be encoded in UTF-8, simply add the utf8 keyword at the end of the geoip_ directives.
This module assigns an identifier to clients by issuing cookies. The identifier can be accessed from variables $uid_got and $uid_set further in the configuration.
Context: http, server, location
Enables or disables issuing and logging of cookies.
The directive accepts four possible values:
Default value: userid off;
Context: http, server, location
Defines the IP address of the server issuing the cookie.
Syntax: userid_service ip;
Default: IP address of the server
Context: http, server, location
Defines the name assigned to the cookie.
Syntax: userid_name name;
Default value: The user identifier
Context: http, server, location
Defines the domain assigned to the cookie.
Syntax: userid_domain domain;
Default value: None (the domain part is not sent)
Context: http, server, location
Defines the path part of the cookie.
Syntax: userid_path path;
Default value: /
Context: http, server, location
Defines the cookie expiration date.
Syntax: userid_expires date | max;
Default value: No expiration date
Context: http, server, location
Assigns a value to the P3P header sent with the cookie.
Syntax: userid_p3p data;
Default value: None
A simple directive is introduced by this module: valid_referers. Its purpose is to check the Referer HTTP header from the client request and possibly to deny access based on the value. If the referrer is considered invalid, $invalid_referer is set to 1. In the list of valid referrers, you may employ three kinds of values:
Following the definition of the $invalid_referer variable, you may, for example, return an error code if the referrer was found invalid:
valid_referers none blocked *.website.com *.google.com;
if ($invalid_referer) {
return 403;
}
Be aware that spoofing the Referer HTTP header is a very simple process, so checking the referrer of client requests should not be used as a security measure.
This module provides one simple feature — it replaces the client IP address by the one specified in the X-Real-IP HTTP header for clients that visit your website behind a proxy or for retrieving IP addresses from the proper header if Nginx is used as a backend server. To enable this feature, you need to insert the real_ip_header directive that defines the HTTP header to be exploited — either X-Real-IP or X-Forwarded-For. The second step is to define trusted IP addresses. In other words, the clients that are allowed to make use of those headers. This can be done thanks to the set_real_ip_from directive, which accepts both IP addresses and CIDR address ranges:
real_ip_header X-Forwarded-For;
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 127.0.0.1;
set_real_ip_from unix:; # trusts all UNIX-domain sockets
This module is not included in the default Nginx build.
Nginx - Additional Modules, About Your Visitors
标签：
原文地址：http://www.cnblogs.com/huey/p/5770543.html
