BossTDS - Manual

Introduction

IF YOU RUN THE TDS ON A BOX WITH 1GB RAM OR MORE AND EXPECT HEAVY LOAD - DON'T FORGET TO TURN OFF REQUEST QUEUE IN SETTINGS (MENU TOOLS -> SETTINGS).

The control panel of the TDS is self-exaplanatory. The menu on the top of each page is used to access TDS settings. You can switch interface language by clicking on country flag in the main menu. To log out from the TDS hover your mouse over your login in the upper right corner and click 'logout' in the drop-down menu.

To check if your TDS can access license servers and if your license valid navigate to the main page (click 'BossTDS Dashboard' in the menu) and click 'Validate license' button.

You can always check your system info by clicking 'System Info' on the main page.

There's a builtin help on each page of the TDS. In every editor there's an 'Hint' section - click on it to read a short hint on the editor as a whole. Also there are green question signs at many fields and properties - hover your cursor over these signs to read help on this particular property.

The TDS job is simple: it accepts your traffic and redirects the traffic to different pages according to your rules and request parameters.
Schemes editor

Schemes editor is used to manage your traffic redirection schemes. Each scheme contains one or more OUT URLs - the pages to redirect your traffic to. You send your traffic to the scheme IN Url, and the TDS will redirect the hit to one of OUT Urls, or to the Default OUT url if none of the OUTs accept the hit.

In the editor you see list of all schemes. There's no pagination, so keep the number of your schemes sane. You can enable or disable schemes in this list. To create a new scheme click 'Create new...' button. To delete a scheme click 'delete' (red) button. To edit scheme properties click 'change' (blue) button.
At the bottom of each row there are buttons which allow you to see statistics for this scheme. the small red button with cross is used to rezero statistics.
To edit OUT URLs of the scheme click 'OUTs of scheme' button.

Schemes properties

You can see scheme properties when you click 'change' or 'Create new...' button.

IN Url

The URL you will send your traffic to. For example, if your TDS in installed on http://yourdomain.com, and the value of this field is 'someurl', you will send your traffic to http://yourdomain.com/in/someurl. Should be unique.
You can send your traffic to IN Urls with parameters (http://yourdomain.com/in/someurl?param1=val1&param2=val2) and access these parameters in the scheme.

Enabled

If the scheme is not enabled all hits to the IN url will return 404 not Found error. Same as if the scheme would not exist at all.

Name

Just some short string to find the scheme in the list of other schemes. Not required to be unique, but better to have it unique.

Label

Labels are used to filter schemes in the schemes editor. If you have several schemes which are related to each other somehow, assign to them the same label and you will be able to easily filter out all other schemes in the schemes editor and in the reports. Not nesssessary, but sometimes useful.

Description

Just some comment about this scheme.

Default OUT Url

If the TDS canot redirect a hit to any of its' OUTs (all OUTs reject) the hit will be sent to this Url.
Formats: http://foo.bar - to redirect to http://foo.bar; boss://inurl - to make an internal redirect to the scheme with IN url equals to 'inurl'; code://[code]/[message] - to return HTTP respanse with given code and message, for example code://404/Not found or code://403/Forbidden.
This field is required.

UTTL

Tracking. A visitor will be considered non-unique for the UTTL hours after first hit.

Track Uniques by

How to track uniques - by IP (which is often the same for different users) or by cookies (which could be easily cleaned). Both options have their own pros and cons.

Enable client checks

This options allow you to check for client (browser) capabilities, such as if the client supports Flash, Javascript, if the URL opened in a frame and browser window dimensions. It is impossible to preserve referer when this option is checked. Also this option makes redirections slower, as it does redirection 2 times instead of one. When it is checked the rule 'Client checks' becomes available.

Custom statistics - templates

You can assign custom reports templates to your scheme to write reports with data according to the template. Each template is, basically, consists of a list of variables to be stored in this report.
Such reports slow down the TDS and could require large amount of HDD space, so do not use too many of such reports and try to choose the list of variables which would aggregate data as much as possible.

Rules

These rules work as a pre-filter. They will be checked prior to the rules of the OUTs.
Each rule specifies either to accept requests that match the rule specification, or to reject them.
If ANY rule rejects, visitor will be sent to the Default OUT URL of the Scheme immediatelly. No OUTs will be tested.
Read more about rules in the 'Rules' section of this manual.

Transformations

Variables, created from these transformations, will be available in every OUT of this scheme. You can override the variables later in transformations of OUTs.
Transformations are used to create variables; you can use these variables in custom reports or as a part of the OUT URL or Default OUT Url in the form http://foo.com?bar={{ variable }}. {{ varname }} will be replaced with the value of the variable 'varname'.
Read more about variables and transformations in the 'Variables and Transformations' section of this manual.

Public statistics

You may want to grant someone the right to see daily stats, for example, to the buyer of your traffic. Leave password field empty to disable this feature.

Public statistics - Password

Password for public statistics for this scheme. Empty means public statistics disabled.

Public statistics - Valid from

The password will be valid from this date. Empty field means no restrictions.

Public statistics - Valid to

The password will be valid to this date. Empty field means no restrictions on end date.
OUT URLs editor
The OUT if the end point of traffic redirection chain. The traffic flows in through IN URL of a scheme and flows out through one of the OUTs of the scheme.
Technically, OUT URLs exist only as a part of scheme. When you delete a scheme you delete all the OUTs of the scheme as well.
Before creating a new OUT you must choose the scheme for thes OUT.

Each OUT either accepts request or rejects, according to the OUT settings. When not a single OUT accepts the request, the hit will be redirected to the Default OUT of the scheme.
What happens if the one or more OUTs accept the request depends on if the OUT belongs to 'Sequential' group or to 'Weight' group.

There are two groups of OUTs - Sequential and Weight. It is vital to understand the differences between these two groups properly.

Sequential OUTs

Sequential OUTs is used to filter traffic by traffic parameters. These OUTs will be tried first. Visitor will be redirected to the first Sequential OUT which accepts the current request parameters (ordered by 'Order' field, low-to-high, the first will be the one with the lowest 'Order'). Sometimes the Order does not matter, when OUTs with the same 'Order' have mutually exclusive rules (for example, one of the OUTs accepts US only traffic and another UK only). Sometimes it does matter a lot, when the rules are not mutually exclusive (for example, when one OUT accepts US only traffic, and another accepts any traffic - in this case you must set the 'Order' right to make the OUT for US traffic checked first).

If none of Sequential OUTs accept the request, then BossTDS will check Weight OUTs.

Weight OUTs

Weight OUTs are used to rotate traffic between a set of pages. These OUTs will be tried when none of Sequential OUTs accept the request. Every Weight OUT will be checked if it accepts the request or not. From the list of the OUT which found to accept the request will be choosen one, randomly, with the probability according to the relative weight of each OUT.
For example, if there are four OUTs (let's name it A, B, C, D) with the weights W_A = 2.0, W_B = 3.0, W_C = 4.0, W_D = 5.0, and A, B, C accept the current request and D does not accept, the OUT to redirect to will be choosen randomly from the list of [A, B, C]. Probablility of redirect to A will be 2.0/(2.0+3.0+4.0) = 0.22 (22%) , to B 3.0/(2.0+3.0+4.0) = 0.33 (33%) , to C 4.0/(2.0+3.0+4.0) = 0.44 (44%).
These probabilities can be skewed if 'Forced rotation for non-uniques' option is set for this group: in this case for unique visitors probabilities will be the same, but for non-unique visitors OUTs which the user have not visited yet will have priority over already visited OUTs regardless of the weights. This behaviour is usually what most people need, so this option is turned on by default.
If none of Weight OUTs accept the request the wisitor will be sent to the Default OUT Url of the scheme.

There are a few controls for each OUTs group: you can click 'New Out...' button to add an OUT to this group; You can use green arrows to move OUT up or down (thus changing the order or even a group); You can Enable/Disable the OUT, change it or delete.

Exclusive controls for Weight OUTs only:

Forced rotation for non-uniques

When checked, repeated visitors will be redirected each time to the new OUT (if this is possible). Otherwise choice is absolutely random no matter if the visitor is repeated or not.
Usually you'd want to have this option enabled, but this might skew weights if there are many hits from repeated visitors.

Mass Add... button
- Used to add a list of Weight OUTs which have the same properties. Instead of adding each OUT one after another you may click his button and input the URLs of the OUTs in a multiline field, one URL per a row. A new OUT will be automatically created for each URL.

OUT URLs properties

You can see OUT properties when you click 'change' or 'Create new...' button.

OUT URL

The URL of the page to redirect to. Formats: http://foo.bar - to redirect to http://foo.bar; boss://inurl - to make an internal redirect to the scheme with IN url equals to 'inurl'; code://[code]/[message] - to return HTTP respanse with given code and message, for example code://404/Not found or code://403/Forbidden.
You can use variables in this field: http://foo.com?bar={{ variable }}. Variables are created automatically from the GET parameters of the request (for example, if your TDS is installed on http://yourtds.com domain and the hit was to http://yourtds.com/in/inurl?q=val1&p=val2, two variables will be created - 'p' with value 'val1' and 'p' with value 'val2') and also can be created manually in the Transformations section.

Enabled

When the OUT is not enabled it will be skipped.

Description

Just some comment about this OUT.

Active from

This OUT URL will be active (accept hits) from this date, including the date listed. Format: MM/DD/YYYY. Empty field means no restrictions.

Active to

This OUT URL will be active (accept hits) to this date, including the date listed. Format: MM/DD/YYYY. Empty field means no restrictions.

Order

Sequential OUTs are checked one after one: if first OUT accepts the request - redirect to this out else check the second OUT and so on. OUTs with lower 'Order' will be checked first. When two OUTs have the same 'Order' priority is not defined. Ignored for Weight OUTs. Must be a postitive integer. When empty or 0 the OUT will be automatically added to the end of Sequential OUTs group.

Weight

The more 'Weight' the OUT has (relative to other Weight OUTs) the more chances for redirection to this OUT. OUTs with 0.0 weight will never be selected for redirection, same as if 'Enabled' would be off. This field is ignored for Sequential OUTs.

Track Uniques by

How to track uniques - by IP (which is often the same for different users) or by cookies (which could be easily cleaned). Both options have their own pros and cons. Pay attention - you might track uniques for scheme by IPs, for some OUTs by cookies and for other OUTs again by IPs. This will work as expected, but rarely needed.

Redirection method

How to redirect your traffic. Location 302 preserves referer, other methods change referer to the address of your TDS. '200 OK, from file' returns content of a file as HTML, JSON or JSONP instead of redirection. The files can be created in the Files editor, they are not the standard OS files.
'Flash (.swf)' returns an .swf file with redirection code. 'Flash (page)' returns HTML page with 'object' tag with flash file assigned to the 'src' attribute.

File/Flash

Name of the File of Flash Refirect for '200 OK, from file' or Flash responses. Disabled for other response types. Must exist. If you delete this file or flash, OUTs which use this file will return 404 response.

Rules

Each rule specifies either to accept requests that match the rule specification, or to reject them.
If ALL rules accept, the visitor will be either redirected to this OUT immediately (if mode is Sequential) or this OUT will be added to the set of potential candidates for redirection in case of Weight mode.
Visitor won't be redirected to the OUT if ANY of the rules rejects.
If you don't care for a rule - delete such rule, as it either accepts only such requests that match it or rejects all such requests that match it.
Please keep number of the rules and their complexity sane.
If you have the same rule for all OUTs of the scheme consider moving it to the Scheme rules.
Read more about rules in the 'Rules' section of this manual.

Limits

Limits on how many hits should be redirected to this OUT. Useful, for example, for the situation when you sell X hits to one buyer (OUT1) Y hits to another one (OUT2) etc.

Max Hits/Day

Maximum hits per day to redirect to this OUT. 0 - unlimited.

Max Hits/Day

Maximum hits per hour to redirect to this OUT. 0 - unlimited.

Total Max. Hits

Total hits to redirect to this OUT. When thois number is reached the OUT stops accepting hits altogether, same as if 'Enabled' would be off. 0 - unlimited.

Calendar limits

A matrix of days of week and hours. You might want to set the limits for the particular hours of particular days. 0 here meand 0 hits (OUT disabled), to have no limits clear the cell.

Transformations

Transformations are used to create variables; you can use these variables in custom reports or as a part of the OUT URL in the form http://foo.com?bar={{ variable }}. {{ varname }} will be replaced with the value of the variable 'varname'.
If you have the same transformation for all OUTs of the scheme consider moving it to the Scheme transformations.
Read more about variables and transformations in the 'Variables and Transformations' section of this manual.

Dynamic OUT

These settings can be used when you want to dynamically enable/disable the OUT or to get the URL to redirect to from another third-party service (web page).

Dynamic mode

Off - dynamic mode disabled. Keep it off unless you know for sure why you need to turn it on.

Check for HTTP response code - connect to a page with HEAD request and check HTTP response code. Temporarely disable the OUT if the response code not equals to the 'HTTP Code' field. If the field 'Get this page' is empty, check the 'OUT URL', else check the URL from the 'Get this page' field.
Healty pages usually return 200 code. Interval to check can be set in the 'Settings' dialog. Default interval is 10 minutes.

Check if page matches/not matches regexp - download a page with GET request, check if contents of the page matches or not matches given regular expression, disable the OUT if it does not. If the field 'Get this page' is empty, download the 'OUT URL', else download the URL from the 'Get this page' field.
Interval to check can be set in the 'Settings' dialog. Default interval is 10 minutes.
For example, to check if page contains word 'foo' input 'foo' (without apostrophes) into the 'Regexp' field.

Read OUT URL from page - download a page with GET request, extract first row of the downloaded page, redirect to this row. If the field 'Get this page' is empty, download the 'OUT URL', else download the URL from the 'Get this page' field.
If checkbox 'Get every hit' is checked, the OUT will be downloaded from remote page on each hit. It does not recommended to set it checked, this greatly slows down the TDS and results in traffic loss. If it is not checked, the URL will be downloaded every N minutes, this interval can be set in the 'Settings' dialog. Default interval is 10 minutes.

Force hits

Forces are ignored for Sequential OUTs as they affect the Weight of an OUT. Forces can be used to temporarily increase or decrease weight of the OUT according to schedule. For example, something like this could be accomplished via Forces: Enable the OUT only on Fridays and Saturdays from 18:00 till 19:30, with priority linealy increasing from 0 at 18:00 to 20 at 19:30, and stop when 1000 hits accumulated.
There are many different use cases for the forces, they are quite powerful tools to imitate behaviour of live traffic or ensure you will be placed in the top of trades which renews every day at set hours. But if you don't know what for exactly you want to use forces - don't use them, as they can slow down the TDS.

Each force contains the following fields:

Schedule - the schedule for the force. When the force should be started, and how long the force should last.
There are two types of forces: daily and hourly.
Format:

Daily: D; days; start time(H:M); duration in minutes. For example:

D;*;0:00;1440 - every day, starts in 0:00, duration 24 hours (1440 = 60*24)

D;1,6,7;19:25;275 - every Mo, Sa, Su, starts in 19:25, duration 275 minutes (4 hours and 35 minutes), i.e until midnight. Please note: at the moment daily forces are intra-day only, so in this example you cannot make duration more than 275 minutes

Hourly: H; days; hours; start time(M); duration in minutes. For example:

H;*;*;0;60 - every day, every hour, duration 60 minutes

H;1,6,7;11,13,19;25;35 - every Mo, Sa, Su three times a day in 11:25, 13:25 and 19:25, duration 35 minutes. Please note: at the moment hourly forces are intra-hour only, so in this example you cannot make duration more than 35 minutes

where day - a number from 1(Mo) to 7(Su); start hour - a number from 0 (00:00) to 23 (23:00)

+Begin - Value to add to the base Weight of the OUT at the start of the force. Can be negative.

+End - Value to add to the base Weight of the OUT at the end of the force. Can be negative. '+Begin' and '+End' can be used to create 'flat' forces when they equal to each other or 'hill' forces - linearly increasing/decreasing forces when they are not equal.

Max/run - Maximum hits per single time interval (single force run). After the force accumulates this number of hits it will be stopped before the time is up. The force will be restarted at the next start time according to the schedule. 0 - unlimited.

Max/total - Maximum total hits. When this limit is reached the force will be disabled forever. It won't restart on the next start time. 0 - unlimited.

Public statistics

You may want to grant someone the right to see daily stats, for example, to the buyer of your traffic. Leave password field empty to disable this feature.

Public statistics - Password

Password for public statistics for this scheme. Empty means public statistics disabled.

Public statistics - Valid from

The password will be valid from this date. Empty field means no restrictions.

Public statistics - Valid to

The password will be valid to this date. Empty field means no restrictions on end date.

Hide URLs for guests

Hide URLs of target page in the public reports. useful when you sell the traffic via intermediate pages which you want to hide.
Rules
Rules are the filters you can apply to your traffic on global (Global Filters/Transforms editor) per scheme (Schemes editor) and per OUT (OUTs editor).
Each rule either accepts the request or rejects it. The OUT will accept the request only if ALL the rules assigned to it accept the request. if any of rules rejects - the OUT rejects immediatelly. The same is true for Schemes - in case when any of the scheme rules reject visitor will be redirected to the 'Default OUT Url' immediatelly, standatd OUTs will be skipped altogether.

The rules are the heart of the BossTDS - by writing the rules you split your incomming traffic stream into different target pages. Please keep the number of the rules sane.

Rules list

1. Proxy

This rule is used to split traffic from behind proxies and direct traffic. Some proxies are impossible to detect though. Don't consider all traffic from behind proxies as outright bad one - there are many legit people who connect to Internet through proxy. Unusually high number of proxies in your traffic is a bad sign though.

2. Empty referer

This rule is used to split traffic with referers and without. Traffic without referes is typen traffic, bookmarks traffic or bot traffic.

3. Unique hits

This rule is used to split unique and repeated visitors. Visitor can be repeated for the whole TDS (was redirected at least once to any of OUTs of any of Schemes), for this scheme only (was redirected to any OUT of the scheme) and for this OUT only (was redirected to this OUT).
You can choose which type of uniqueness should be checked - Global, Scheme or OUT. A visitor is considered repeated (non-unique) when he/she hits the same Scheme or the same OUT second time per interval which can be set in the Scheme properties ('UTTL' field).
Useful when you want to redirect visitors to one of your pages only onse per time interval.

4. IP ranges

Reject or accept clients with IPs which fall in any of IP ranges. You can choose which IP should be checked: Client IP - real IP behind proxy; Peer IP - proxy IP if proxy detected, otherwide equals to the Client IP; Peer or Client - check if any of these IPs are in the range.
There are two fields - 'IPs/Subnets' and 'IP lists'.

IPs/Subnets - you can input here comma-separated IPs and subnets if you have just a few of them. Allowed formats: xxx.xxx.xxx.xxx (single IP), xxx.xxx.xxx.xxx/xx (CIDR subnet), xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx (IP range). for example, 77.1.233.3,66.67.11.0/24,55.1.1.0-55.1.20.055. When you have large list of ranges use IP Lists instead of this field.

IP Lists - IP lists are created in the IP Lists editor. When you change an IP list it automatically updates itself in every rule where it is used. Lookup in IP lists is optimized for speed and has O(logN) complexity, so lookups are quite fast even when the list is quite large.

The IP is considered 'in range' when it falls into one of the ranges in the 'IPs/Subnets' field OR into any of the ranges of any of the IP Lists.

5. GeoIP

This rule is used to filter your traffic by countries and/or cities. Uses MaxMind GeoIPLite legacy database.
By default GeoIP City database is disabled to save memory, you can turn it on in the Settings dialog.

Country - choose some countries. FYI - United Kingdom is not UK here, it is GB.

Country groups - country groups are predefined lists of countries which are created in the Country groups editor.

City - comma-separated list of cities (english names). This database is not reliable - up to 70% for US cities, way less for the rest of the world. By default this database is disabled and the city is always empty string.

Region - comma-separated list of regions (FIPS codes). In USA region is an abbreviation of states names (for example TX). In some other countries it is digits (for example 09, 71 etc - with leading zero). List of FIPS region codes can be found here. Since v. 4.9.4 the TDS uses ISO 3166-2 codes. Look up the regions here: en.wikipedia.org/wiki/ISO_3166-2 - go to the page and click the country code in the 'Entry' column of the table. You can now use both short region codes and the codes with the country. For example CM or ES-CM for Castilla-La Mancha in Spain.

The hit is considered to be 'from country/city/region' if its' country equals to any of countries from 'Country' field OR to any of countries of any of country lists in 'Country groups' field AND to any of cities in 'City' field AND to any of regions in "Region' field . When any of these fields is empty it will be simply ignored, so if 'Cities' field is empty only countries will be checked.

6. Browser locale

Browsers usually send 'accept-language' HTTP header which contains list of preferred locales in the form like 'en-gb,en;q=0.7,de;q=0.3'. This rule is used to filter hits by this header. It checks if any of given locales (in the form of, for example, 'en,fr,ru-ru') is equal to any of locales from the 'accept-language' header. The check is considered successful if at least one pair matches.
When 'Primary locale only' checkbox is on, only the first value from 'accept-language' header is checked.

7. Cookies

This rule is used to check if HTTP client accepts cookies or not. It requires additional redirect (to set a cookie and to read it). Standard browsers usually do accept the cookies.

8. GET Parameter

This rule is used to make filters by values of GET parameters. For example, if your TDS is installed on http://yourtds.com domain and the hit was to http://yourtds.com/in/inurl?q=val1&p=val2 there will be two GET parameters - 'q' with value 'val1' and 'p' with value 'val2'. In the rule you specify what to do if a GET parameter with given name matches or not matches regular expression, equals or not equals a string, less than or greater than some value (in this case value should be valid number, with or without decimal point).
If you need to have filter for another GET parameter just add another 'GET Parameter' rule.
If rule exists and the hit was without such GET parameter, the value is assumed to be an empty string.
Parameter names and values are assumed to be not case-sensitive.

9. HTTP Header

This rule is used to make filters by values of HTTP request headers. It allows you to check if value of a header with given name matches or not matches regular expression.
Header names and values are assumed to be not case-sensitive.

10. Browser/OS

This rule allows you to make filters based on the following data extracted from User-Agent string:

Browser Family - such as Firefox, IE etc

Browser Type - if the browser is Mobile, Desktop, Mail, Text, Bot, Tool, Unknown

Browser Engine - such as Presto, Webkit, Trident etc

Browser Manufacturer - MS, Apple, Google etc

OS Family - Windows, Linux, OSX, iOS, Android...

OS Type - if the OS is Desktop, Mobile, Tablet, Console etc

OS Manufacturer - MS, Google, Apple, Nokia etc

For example, if you set Browser Family as 'Firefox, IE', OS Family as 'Windows, OSX' and Browser Type as 'Desktop' the rule will select the following clients: (Browser is Firefox OR Internet Explorer) AND (OS Family is Windows OR any OSX) AND (Browser Type is Desktop). As a result clients with Firefox on Windows will be accepted, with Firefox on Linux rejected, with IE on Windows accepted, with Firefox on OSX accepted, with Safari on OSX rejected, with IE 11 on Windows Phone 8 accepted if IE works in 'Full wersion' and rejected if it works in 'Mobile version' (there's such setting in the WinPhone8 IE11).
User agent can be easily faked, but it is the only way to get this information from HTTP request.

11. 3G/GPRS

Allows you to split your traffic to 3G and WiFi - sometimes users have different behavioural patterns which depend on whether they use the same device at home (WiFi connection) or outside (3G connection). It makes sense to use this filter together with Browser/OS filter for mobile devices only.
You can specify exact carriers you care of. When you don't select any carrier it means 'All Carriers'.
3G detection is based on known IP ranges of cellular providers and optimized for speed. This filter is not very precise, 'GeoIP2 Connection Type' filter (see below) is better but requires a paid database from MaxMind.

12. J2ME MIDP

Allows you to select only devices which support J2ME MIDP standard, optionally with given MIDP version only. Field 'Version' must be empty (in this case Version is ignored) or contain a version number like '2.1'.
Based on HTTP User-Agent request header.

13. Client checks

Allows you to check client (browser) capabilities. This rule is visible only when 'Enable client checks' option of the Scheme is checked.
It is impossible to preserve referer when this option is checked.

Javascript - check if browser supports javascript

Flash - check if browser supports Adobe Flash

iFrame - check if the link is opened in a frame or not

Viewport size - check browser window dimensions

Reject if any check succeeds - if any check returns true (for example when javascript is not supported by the client and 'Javascript' option is set to 'Is not supported') the rule will reject the request.

Reject if any check succeeds - if all check returns true the rule will reject the request. If at least one returns false the rule will accept.

Accept if at least one check succeeds - if any check returns true (for example when javascript is supported by the client and 'Javascript' option is set to 'Is not supported' and flash is not supported and 'Flash' option is set to 'Is supported' ) the rule will accept the request.

Accept if all check succeed - if all check returns true the rule will accept the request. If at least one returns false the rule will reject.

14. Sequence of hits

Reject/Accept if the visitor is not unique and has been already redirected to any/all OUTs from the given list (current scheme only).
The list should contain comma-separated list of OUTs IDs. Only the OUTs from the same scheme are allowed.

This filter can be quite slow when the list is large.

15. GeoIP2 Connection Type

Reject or accept requests made from specific connection type(s), detected by IP.
This filter uses GeoIP2 Connection Type database from MaxMind, you need to purchase the database, unzip it, upload the GeoIP2-Connection-Type.mmdb file into /opt/bosstds/deps/geodata2/priv/ directory and activate it in the Settings dialog.
The 'GeoIP2 Connection Type' filter is much more precise than 3G/GPRS filter. Use it if you can afford to purchase the database.

16. GeoIP2 ISP

Reject or accept requests made from a specific ISPs, detected by IP.
This filter uses GeoIP2 ISP database from MaxMind, you need to purchase the database, unzip it, upload the GeoIP2-ISP.mmdb file into /opt/bosstds/deps/geodata2/priv/ directory and activate it in the Settings dialog.

Check - for each IP the database returns two fields - ISP and organization. Either of both of them can be empty. They are often the same, but sometimes they are not. You can choose which value you want to compare to - ISP, Organization or Both. Both meand 'either' in this context.

ISP Lists - ISP lists are just lists of ISP and/or Organization names. They are created in the GeoIP2 ISP Lists editor. The filter looks if the current ISP, detected by IP, contains in any of these lists.
Variables and transformations
Transformation is a powerful mechanism used to construct dynamic URLs based on request parameters, to extract and transform some request data, save this data and use it in OUT URLs and in extended reports.
TDS automatically created a variable for each request query GET parameter - for example, if your TDS is installed on http://yourtds.com domain and the hit was to http://yourtds.com/in/inurl?var1=val1&var2=val2 there will be two variables available - 'var1' with value 'val1' and 'var2' with value 'val2'. Transformations are used to create variables manually.
You can use variables in OUT URL, in the form like http://foo.bar?some={{ var1 }}&other={{ var2 }}. So if the hit was to http://yourtds.com/in/inurl?var1=val1&var2=val2 and OUT URL equals to http://foo.bar?some={{ var1 }}&other={{ var2 }}, the visitor will be redirected to http://foo.bar?some=val1&other=val2.
There are five filters which can be used on variables:

URLDECODE2 - applies urldecode two times on the value of the parameter instead of once by default;

SE - extracts search engine (such as 'Google') from search engine referer;

SE_FULL - extracts full search engine (such as 'google.fr') from search engine referer;

KEYWORD - extracts search keyword from search engine referer;

DOMAIN - extracts domain from a variable which should be valid urlencoded URI string, otherwise will be empty.

Use the following syntax for filters: http://foo.bar?some={{ var1|FILTERNAME }}, for example http://foo.bar?some={{ var1|SE_FULL }}. This example means: take value of a variable with name 'var1', extract search engine from the value, put it in a query. The 'var1' variable should contain an urlencoded search engine referer, such as, for example, http%3A%2F%2Fwww.bing.com%2Fsearch%3Fq%3Dbuy%2Bshoes%2Bonline%26form%3DTMXFRH%26pc%3DUP97%26mkt%3Dfr-fr%26scope%3D%26pq%3Dsilde%26sc%3D8-5%26sp%3D2%26qs%3DAS%26sk%3DAS1

Transformations list

There are five types of transformations which create variables manually:

GET Param

Take value of the given GET parameter; find 'Search' and replace with 'Replace' (you can leave these two fields empty if you don't need to replace anything); put result in the variable with given name. You can use Erlang regex search/replace syntax. Look up http://www.erlang.org/doc/man/re.html or contact our support for help. You may also apply one of the filters metioned above on the 'Input' field, for example, paramname|DOMAIN;

HTTP Header

Take value of the given HTTP request header; find 'Search' and replace with 'Replace' (you can leave these two fields empty if you don't need to replace anything); put result in the variable with given name. You may also apply one of the filters metioned above on the 'Input' field, for example, paramname|DOMAIN;

Constant

'Search' and 'Replace' fields are ignored; data (string) from 'Input' will be put into 'Variable' as is. Useful for JSON(P) ads serving as additional field for, for example, image name.

Random

Creates a variable with a random alphanumeric string. 'Search' and 'Replace' fields are ignored; 'Input' should contain a number from 1 to 128 - the count of characters in the string.

Variant

Creates a variable with content chosen randomly from the Variants list with given name. 'Search' and 'Replace' fields are ignored; 'Input' should contain the name of a variants list. A Variants List is just a list of string values. Variants Lists are created in the Variants Lists editor.

As was mentioned above, each transformation creates a variable with a given name. So for any hit the following variables are available: an one variable for each request query GET paramater + variables created from transformations of the OUT which accepted the request + variables created from transformations of the current scheme + global variables which can be configured in the Global Filters/Transforms editor.
You can use these variables in exactly the same way (for OUT URL substitutions and in extended reports), you can apply filters on them etc.
Macros editor

Macros are used as a repository for regular expressions. If you use the same regexp in many OUTs, you can save it as macros instead and use {% MACROS_NAME %} instead of the regexp.

Macros' are rarely used and I consider removing this feature in the future. If you still going to use it be sure you don't delete a macros when it is used in any of OUTs.

Macros properties

Name

Name of the macros. Can be used in the form {% MACROS_NAME %} in any OUT property that accepts regexp as input;

Enabled

When the macros is not enabled it is the same thing as if the macros would not exist at all;

Value

The regexp itself. Instead of writing the same regexp many times, save it onse in a macros and use macros name instead.
Files editor
Files are used in OUTs for '200 OK, from file' response types. In this case the TDS, instead of redirection, takes contents of the File, replaces any variables found in the content with actual values (extracted from the request parameters) and returns this content as HTML, JSON or JSONP. This is useful when you want to use the TDS as data provider for some client-side javascript code, for example for ads serving or cloaking.

File properties

File Name

Name of the file. To be used in 'File' field in the OUT properties. Must be unique;

Content Type

HTML - the response will be returned with 'text/html' content type header;

JSON - the response will be returned with 'application/json' content type header;

JSONP - the response will be returned with 'application/json' content type header and the content will be wrapped in callback function. Function name will be 'callback' unless there's a GET parameter with name 'callback' - in this case valuue of this parameter will be used as function name.;

Description

Just some short comment about this file

File Data

Content of the file. You may use variables in the content in the same way as in OUT URLs - {{ varname }}. besides standatd variables (see 'Variables and Transformations' section of this guide) the following predefined variables also available:

__BROWSER_NAME__ - Browser Name, from User-Agent

__BROWSER_FAMILY__ - Browser Family, from User-Agent

__BROWSER_TYPE__ - Browser Type, from User-Agent

__BROWSER_MANUFACTURER__ - Browser Manufacturer, from User-Agent

__BROWSER_ENGINE__ - Browser Engine, from User-Agent

__OS_NAME__ - OS Name, from User-Agent

__OS_FAMILY__ - OS Family, from User-Agent

__OS_TYPE__ - OS Type, from User-Agent

__OS_MANUFACTURER__ - OS Manufacturer, from User-Agent

__GEOIP_COUNTRY_SHORT__ - GeoIP Country code

__GEOIP_COUNTRY_FULL__ - GeoIP Country Name

__GEOIP_CITY__ - GeoIP City

__CLIENT_IP__ - Client IP Address

__PEER_IP__ - Peer IP Address (proxy IP for transparent proxies)

__DATE__ - Current date

__TIME__ - Current time

__REFERER__ - Referer

__OUTURL__ - Url of redirect

__OUTID__ - ID of the OUT

__3G__ - '3G/GPRS' for cellular connection, otherwise 'No'

__3GCARRIER__ - Carrier name (for example 'Vodafone') for cellular connection, otherwise empty

__MIDP__ - 'MIDP' for devices with J2ME MIDP support, otherwise 'No'.

__MIDP_VSN__ - MIDP version (for example '2.0') for devices with J2ME MIDP support, otherwise empty.

__CLIENT_VIEWPORT_W__ - Viewport window width.

__CLIENT_VIEWPORT_H__ - Viewport window heigth.

__CLIENT_VIEWPORT_WH__ - Viewport window width*heigth.

__CLIENT_JS__ - true when client supports javascript otherwise false.

__CLIENT_FLASH__ - true when client supports Adobe Flash otherwise false.

__CLIENT_FRAME__ - true if URL opened in a frame otherwise false.

__PROXY__ - true when proxy detected otherwise false.

__NOREF__ - true when referer is empty otherwise false.

__GEOIP2_CONN_TYPE__ - GeoIP 2 Connection type.

__GEOIP2_ISP_ISP__ - GeoIP 2 ISP.

__GEOIP2_ISP_ORG__ - GeoIP 2 ISP organization.

__GEOIP2_ISP_ASN__ - GeoIP 2 ISP ASN.

For example, content could look like this: {"url": "{{ __OUTURL__ }}", "pix": {{ pixparam }}, "message": "Hello World!", "code": 0}
Custom Reports Templates editor
Custom Reports Templates are the templates of reports, which can be assigned to Schemes. A template consists of a number of variables (see 'Variables and Transformations' section) which will be saved in the report and can be accessed later in the 'Reports -> Custom' menu.

Custom reports are stored daily, with 30 days history max for each report. They are available as Tab-Separated files or can be viewed in HTML interface (first 1000 rows only). Custom reports can take signifficant disk space (more than you expect) and memory; they slow down TDS as well. So don't assign too many extended reports to your schemes.

Another tip: choose variables for your reports wisely. For example, storing client IP address in the custom reports wouldn't be a smart thing as for each IP a new row will be created and IPs are usually different for every hit. Storing OS Name with Browser Name is fine, as there's only so much combinations of these two parameters. Referer could be tricky, depending on your traffic - you really don't want to DoS your TDS with hits with everchange referers. When you have one variable with just a few possible values and another variable with huge number of possible values it is often better to create two different templates - one for the first variable and another for the second and have two smaller reports instead of one large one.
If you unsure whether particluar report is viable or not, contact our support, we will be glad to help.

Custom Reports Templates properties

Name

Name of the template. Must be unique;

Parameters List

Comma-separated list of variables to be stored in this report. You may apply filters on the variables as well - see 'Variables and Transformations' section.
Besides standard variables, the following predefined variables also available:

__BROWSER_NAME__ - Browser Name, from User-Agent

__BROWSER_FAMILY__ - Browser Family, from User-Agent

__BROWSER_TYPE__ - Browser Type, from User-Agent

__BROWSER_MANUFACTURER__ - Browser Manufacturer, from User-Agent

__BROWSER_ENGINE__ - Browser Engine, from User-Agent

__OS_NAME__ - OS Name, from User-Agent

__OS_FAMILY__ - OS Family, from User-Agent

__OS_TYPE__ - OS Type, from User-Agent

__OS_MANUFACTURER__ - OS Manufacturer, from User-Agent

__GEOIP_COUNTRY_SHORT__ - GeoIP Country code

__GEOIP_COUNTRY_FULL__ - GeoIP Country Name

__GEOIP_CITY__ - GeoIP City

__CLIENT_IP__ - Client IP Address

__PEER_IP__ - Peer IP Address (proxy IP for transparent proxies)

__DATE__ - Current date

__TIME__ - Current time

__REFERER__ - Referer

__OUTURL__ - Url of redirect

__OUTID__ - ID of the OUT

__3G__ - '3G/GPRS' for cellular connection, otherwise 'No'

__3GCARRIER__ - Carrier name (for example 'Vodafone') for cellular connection, otherwise empty

__MIDP__ - 'MIDP' for devices with J2ME MIDP support, otherwise 'No'.

__MIDP_VSN__ - MIDP version (for example '2.0') for devices with J2ME MIDP support, otherwise empty.

__CLIENT_VIEWPORT_W__ - Viewport window width.

__CLIENT_VIEWPORT_H__ - Viewport window heigth.

__CLIENT_VIEWPORT_WH__ - Viewport window width*heigth.

__CLIENT_JS__ - true when client supports javascript otherwise false.

__CLIENT_FLASH__ - true when client supports Adobe Flash otherwise false.

__CLIENT_FRAME__ - true if URL opened in a frame otherwise false.

__PROXY__ - true when proxy detected otherwise false.

__NOREF__ - true when referer is empty otherwise false.

__GEOIP2_CONN_TYPE__ - GeoIP 2 Connection type.

__GEOIP2_ISP_ISP__ - GeoIP 2 ISP.

__GEOIP2_ISP_ORG__ - GeoIP 2 ISP organization.

__GEOIP2_ISP_ASN__ - GeoIP 2 ISP ASN.

For example, from|SE_FULL,someparam,from|KEYWORD,__BROWSER_TYPE__ will create a report with search engine name extracted from variable 'from' which contains search engine referer + value of variable named 'someparam' + search keyword, extracted from variable 'from' which contains search engine referer;

Titles List

Comma-separated list of column titles shown in the report. When empty, variable names from 'Parameters List' will be used as titles. When not empty, the number of titles should be exactly the same as the number of parameters;

Mode

Scheme - the report will be saved separately for each scheme with this report;

Global - the report will be saved for all schemes with this report together in a single file.

Keep Hit Count

When on, each row in the report will contain number of hits. When off, this number will be always 0, but this mode is somewhat faster. For example, you may have this option off if you care about which referers send hits to your TDS but do not care how many hits from each referer.

Description

Just some short comment about this template.
Country Groups editor

Country Groups can be used in GeoIP rules. Instead of creating the same countries lists from scratch every time, just save them once as Country Group and use Group Name instead. As a bonus, when you update Country Group, all changes are automatically propagated to all the OUTs which use this group.

Country Groups properties

Group Name

Name of the group;

Countries

List of countries which belong to this group;

Description

Just some short comment about this group.
IP Lists editor

IP Lists can be used in IP Ranges rules. IP List is a text file which contains IPs and IP ranges, one IP/IP range per row. Valid formats: x.x.x.x/xx (CIDR subnet); x.x.x.x-x.x.x.x (IP range); x.x.x.x,x.x.x.x (IP range); x.x.x.x (single IP).
Rows with unrecognised data will be skipped.

You can download the list back from the TDS to your PC later by clicking 'download' button in the IP Lists editor.

IP Lists are optimized for speed, lookup has complexity of O(logN), so the lists with tens of thousands IPs and IP ranges could be handled without much slowdown.

IP Lists properties

Name

Name of the IP List;

File

Text file with IPs and IP ranges, one IP/range per row;

Description

Just some short comment about this IP list.
Variants editor

Variants (or, to be more precise, Variants Lists) are used in transformations of type 'Variants'. Such transformations create variables with a random value chosen from a Variants List with given name. Maximum string (variant) size is 512 bytes. Maximum file size is 65535 bytes. Encoding should be UTF-8 without BOM.

You can download the list back from the TDS to your PC later by clicking 'download' button in the Variants editor.

You can imitate exactly the same functionality by creating a single Weight OUT for each of variants. Variants are usually faster than dedicated OUTs, but they don't allow setting filters and limits on choices and they don't have separate statistics (you can use custom reports though). Usually you would want to use variants instead of OUTs when you just want to randomly replace a part of OUT from the set of many choices without precise statistics.

Variants properties

Name

Name of the variants List;

File

Text file with variants, one variant per row. Maximum file size 65535 bytes, maximum row size 512 bytes;

Description

Just some short comment about this Variants list.
Flash Redirects editor

Flash redirects are used to make redirects via Adobe Flash (.swf) files. BossTDS injects the target URL into .swf file on the fly. In Flash Redirects editor you can create and modify flash files with redirection code inside, which are to be used later in OUTs editor for flash redirects.

A Flash redirect is an .swf file which contains redirection code and a String buffer for actual target URL. There are three default .swf redirects - first redirects immediatelly, second with 0.3 sec delay and third when user moves a mouse over the flash file. You can add your own flash redirects - a few example AS3 files and a shell script to compile the files are included (directory bosstds/priv/flash-redir-src of bosstds installation).

BossTDS injects URL into flash file on the fly without recompiling. It does this the following way: it searches a given string in the flash file and assumes this string marks the start of the buffer of given length. Then it replaces the buffer with actual URL and fills the rest of the space in the buffer with zeros. If the actual URL is longer than the buffer size, the URL will be truncated to fill the buffer. When you create the flash file make sure you allocate enough space for the buffer - make it long and just fill it with spaces or whatever characters you want. Have a look onto the example .as files to understand what is this paragraph about.

Flash properties

Name

Name of the Flash Redirect;

Flash file

.swf file with redirection code and buffer for the actual URL.

Buffer start pattern

A strings that marks start of the buffer in the file. Min 8 characters long.

Buffer size

A size of the buffer. If the target URL is longer than this buffer, it will be truncated.

Description

Just some short comment about this Flash redirect.
GeoIP2 ISP Lists editor

ISP lists are used in GeoIP2 ISP filter. To use this filter you have to purchase GeoIP2 ISP database from MaxMind, unzip it and upload it in the bosstds/deps/geodata2/priv/ directory.

You can use both ISP and Organization fields from the database.

ISP Names are case sensitive. Input the names as they are in the database, without any modifications.

While lookups are optimized for speed and even large ISP list won't slow the TDS too much, they could require quite a few RAM, so create your ISP lists with caution on low-memory servers.

If you need full list of all available ISPs and organizations, ssh to the server, navigate to /opt/bosstds/ and run ./init.sh dumpisp command. The list will be saved in bosstds/priv/ispdump.csv file. Prior to running this command the TDS must be started and GeoIP2 ISP database must be activated in the Settings dialog. Another way to get the names is to create a custom report template with __GEOIP2_ISP_ISP__ and __GEOIP2_ISP_ORG__fields, assign it to your scheme and send some test traffic to the scheme. Then look up the names in the report.

GeoIP2 ISP Lists properties

Name

Name of the ISP List;

ISPs

A list of ISP names, one per row. Warning - large lists can take quite few RAM.

Description

Just some short comment about this ISP list.
Global Filters/Transforms

Global filters and transformations are used to create Rules and Transformations which are executed for every hit directed to your TDS.
Global rules can be useful for filtering out bots, bad countries and bad IPs - whenever any global rule rejects, the visitor will be sent to the Default OUT Url of the current sceheme immediatelly; global transformations will create variables which will be available in all schemes and OUTs.

Read more about rules and transformations in 'Rules' and 'Variables and Transformations' sections of this manual.
Settings
In this editor you can configure some global settings for the TDS. Besides these settings, there are some other settings which cannot be changed while IDS is running, such settings can be edited manually in the config file (boss.config).

Settings list

GeoIP Database

GeoIP Country - a database without cities information. You won't be able to filter by cities when you use this database;

GeoIP City - a database with cities information. Takes much more RAM and somewhat slower than Country database; not too reliable - 70% for US cities, much more less for the rest of the world world.

Reload Database button

GeoIP databases are stored in bosstds/deps/geodata2/priv/ directory, as unzipped .mmdb files. You might want to download the latest databases from MaxMind site and replace these standard files. In this case you can click this button to reload database from disk without restarting the TDS.

Bind to IP

Very important setting. You may leave this field empty if you have just one IP on your VPS/Server.
You MUST set this field if you have more than one IP. Input one of the IP adresses you used in your license.
When you move the database from one server to another don't forget to edit this IP!

Dynamic pages check interval

If you use dynamic OUTs, this is the time interval (in minutes) between pages availability checks and downloads of URLs from remote pages.

API key

If you use API you must connect with this key.

Cookies check parameter name

GET parameter name which is used in Cookies rule, in the process of validating if the clien accepts cookies or not.

Flash request parameter name

GET parameter name used to get Flash redirect for Flash (page) redirects.

Proxy IP

Usually you'd want to leave this field empty.
Sometimes it is impossible to distinguish IP of your own reverse proxy from the 'wild' proxies. As a result all hits are detected as if they were made from behind proxy. Input there the IP of your reverse proxy if you have this problem. In most configurations you don't have to do this though, TDS is smart enough. Sometimes this could be fixed by configuring nginx properly.

Request queue

NEVER turn this option OFF if you have a VPS with 512M RAM! TDS will crash when out of memory, and having a small pool of workers still offers more than adequate performance for a small VPS.
Usually you'd want to turn this option OFF when you have 1G RAM or more and expect high load.

ON - requests are processed by a small pool of worker processes. This saves a lot of RAM, but negatively affects performance.

OFF - requests are processed in the context of web server processes. This allows maximum performance, but takes much more RAM under heavy load.

GeoIP2 Connection Type

Allows you to activate MaxMind's paid GeoIP2 Connection Type database. The database must be unzipped, uploaded into /opt/bosstds/deps/geodata2/priv/ directory.

GeoIP2 ISP

Allows you to activate MaxMind's paid GeoIP2 ISP database. The database must be unzipped, uploaded into /opt/bosstds/deps/geodata2/priv/ directory.
Registration

After you've bought the TDS and downloaded bosstds.lic file for your server, input contents of this file on this page.
Don't forget to reboot the TDS after you input the data - /etc/init.d/bosstds/restart from ssh console. And one more point before you reboot - if you have more than one IP on your server, input the IP from your license into the 'Bind to IP' field on 'Settings' page.
API

API is for those who wants to use BossTDS from their own scripts. At the moment there are php and python classes, you can find them in bosstds/priv/scripts/ directory.

At the moment API is an experimental feature, subject to testing and its' functions can be changed in future versions.

PHP API

To access the TDS from php use bossapi.php file. It exports BossAPI class with the following methods:

__construct($apikey, $tdsdomain, $port, $method = 0)

Constructor,
string $apikey, API Key, from Settings dialog;
string $tdsdomain, domain of your TDS, without port;
int $tdsport, port of your TDS server; int $method - method to access the TDS, 0 - file_get_contents, 1 - fsockopen.

public function request($selector, $client_ip=NULL, $headers = NULL)

This function makes request to the TDS and returns result as a dict.
string $selector - URL of a scheme, for example '/api/demoscheme/'. It _MUST_ have leading slash. Pay attention - instead of '/in/' you should use '/api/' here.
string $client_ip - Client IP. If NULL, will be extracted from $_SERVER["REMOTE_ADDR"];
array $headers - additional HTTP request headers, dictionary, contains list of header_name => header_value. By default this class extracts all request headers from $_SERVER global variable and sends them all to the TDS. In the $headers you can override values of headers from $_SERVER or add your own headers;
returns array dict with three elements: 'status' (HTTP code, usually 302), 'location' (URL to redirect to, might be empty if status is not 302, 'body' - body of response, empty for standatd redirects, not empty for other redirects.

Example
include_once("bossapi.php"); $domain = "yourdomain.com"; $port = 18001; $api_key = "LKjmadsa6m"; $boss = new BossAPI($api_key, $domain, $port, 1); $result = $boss->request("/api/demoscheme/"); if (isset($result["status"]) && ($result["status"] == 302)) { header("Location: ".$result["location"]); } else { print_r($result); }

Python (for python 2.7) API

To access the TDS from python use bossapi.py file. It exports BossAPI class with the following methods:

def __init__(self, apikey, tdsdomain)

Constructor,
str apikey, API Key, from Settings dialog;
str tdsdomain, domain of your TDS, with port, for example yourdomain.com:18001;
def request(self, selector, client_ip=None, headers=None)

This function makes request to the TDS and returns result as a dict.
str selector - URL of a scheme, for example '/api/demoscheme/'. It _MUST_ have leading slash. Pay attention - instead of '/in/' you should use '/api/' here.
str client_ip - Client IP. If None, will be 127.0.0.1. If you use Django, place value of request.META.get('REMOTE_ADDR') here;
dict headers - HTTP headers. Contains dict of {header_name : header_value}. If you use Django, you should iterate request.META, extract all values starting with 'HTTP_', replace'HTTP_' with '' and use this dictionary as the last parameter of request() function;
returns dict with three elements: 'status' (HTTP code, usually 302), 'location' (URL to redirect to, might be empty if status is not 302, 'body' - body of response, empty for standatd redirects, not empty for other redirects.

Example
from bossapi import BossAPI boss = BossAPI("LKjmadsa6m", "yourdomain.com:18001") result = boss.request("/api/demoscheme/", "223.14.9.4", {"referer": "http://yahoo.com", "someotherheader": "headerval"} print result['status'], result['location'], result['body'] #If you use Django, you should iterate request.META, extract all values starting with 'HTTP_', replace 'HTTP_' with '' and use this dictionary as the last parameter of request(...) method

Manual

Introduction

Schemes editor

Schemes properties

OUT URLs editor

OUT URLs properties

Rules

Rules list

Variables and transformations

Transformations list

Macros editor

Macros properties

Files editor

File properties

Custom Reports Templates editor

Custom Reports Templates properties

Country Groups editor

Country Groups properties

IP Lists editor

IP Lists properties

Variants editor

Variants properties

Flash Redirects editor

Flash properties

GeoIP2 ISP Lists editor

GeoIP2 ISP Lists properties

Global Filters/Transforms

Settings

Settings list

Registration

API

PHP API

Python (for python 2.7) API