83 lines
3.4 KiB
Plaintext
83 lines
3.4 KiB
Plaintext
DeviceAtlas Device Detection
|
|
----------------------------
|
|
|
|
In order to add DeviceAtlas Device Detection support, you would need to download
|
|
the API source code from https://deviceatlas.com/deviceatlas-haproxy-module.
|
|
The build supports the USE_PCRE and USE_PCRE2 options. Once extracted :
|
|
|
|
$ make TARGET=<target> USE_PCRE=1 (or USE_PCRE2=1) USE_DEVICEATLAS=1 DEVICEATLAS_SRC=<path to the API root folder>
|
|
|
|
Optionally DEVICEATLAS_INC and DEVICEATLAS_LIB may be set to override the path
|
|
to the include files and libraries respectively if they're not in the source
|
|
directory. However, if the API had been installed beforehand, DEVICEATLAS_SRC
|
|
can be omitted. Note that the DeviceAtlas C API version supported is the 2.4.0
|
|
at minimum.
|
|
|
|
For HAProxy developers who need to verify that their changes didn't accidentally
|
|
break the DeviceAtlas code, it is possible to build a dummy library provided in
|
|
the addons/deviceatlas/dummy directory and to use it as an alternative for the
|
|
full library. This will not provide the full functionalities, it will just allow
|
|
haproxy to start with a deviceatlas configuration, which generally is enough to
|
|
validate API changes :
|
|
|
|
$ make TARGET=<target> USE_PCRE=1 USE_DEVICEATLAS=1 DEVICEATLAS_SRC=$PWD/addons/deviceatlas/dummy
|
|
|
|
These are supported DeviceAtlas directives (see doc/configuration.txt) :
|
|
- deviceatlas-json-file <path to the DeviceAtlas JSON data file>.
|
|
- deviceatlas-log-level <number> (0 to 3, level of information returned by
|
|
the API, 0 by default).
|
|
- deviceatlas-property-separator <character> (character used to separate the
|
|
properties produced by the API, | by default).
|
|
|
|
Sample configuration :
|
|
|
|
global
|
|
deviceatlas-json-file <path to json file>
|
|
|
|
...
|
|
frontend
|
|
bind *:8881
|
|
default_backend servers
|
|
|
|
There are two distinct methods available, one which leverages all HTTP headers
|
|
and one which uses only a single HTTP header for the detection. The former
|
|
method is highly recommended and more accurate. There are several possible use
|
|
cases.
|
|
|
|
# To transmit the DeviceAtlas data downstream to the target application
|
|
|
|
All HTTP headers via the sample / fetch
|
|
|
|
http-request set-header X-DeviceAtlas-Data %[da-csv-fetch(primaryHardwareType,osName,osVersion,browserName,browserVersion,browserRenderingEngine)]
|
|
|
|
Single HTTP header (e.g. User-Agent) via the converter
|
|
|
|
http-request set-header X-DeviceAtlas-Data %[req.fhdr(User-Agent),da-csv-conv(primaryHardwareType,osName,osVersion,browserName,browserVersion,browserRenderingEngine)]
|
|
|
|
# Mobile content switching with ACL
|
|
|
|
All HTTP headers
|
|
|
|
acl is_mobile da-csv-fetch(mobileDevice) 1
|
|
|
|
Single HTTP header
|
|
|
|
acl device_type_tablet req.fhdr(User-Agent),da-csv-conv(primaryHardwareType) "Tablet"
|
|
|
|
Optionally a JSON download scheduler is provided to allow a data file being
|
|
fetched automatically in a daily basis without restarting HAProxy :
|
|
|
|
$ cd addons/deviceatlas && make [DEVICEATLAS_SRC=<path to the API root folder>]
|
|
|
|
Similarly, if the DeviceAtlas API is installed, DEVICEATLAS_SRC can be omitted.
|
|
|
|
$ ./dadwsch -u JSON data file URL e.g. "https://deviceatlas.com/getJSON?licencekey=<your licence key>&format=zip&data=my&index=web" \
|
|
[-p download directory path /tmp by default] \
|
|
[-d scheduled hour of download, hour when the service is launched by default]
|
|
|
|
Noted it needs to be started before HAProxy.
|
|
|
|
|
|
Please find more information about DeviceAtlas and the detection methods at
|
|
https://deviceatlas.com/resources .
|