HPCE/gitea-pages
0
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Activity

content update

Browse Source
This commit is contained in:
Tom Johnson
2015-04-20 16:48:21 -07:00
parent 55b3280762
commit 5b5bf8858e
186 changed files with 32 additions and 64651 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
_includes/reuse/endpoint_descriptions.md
View File

@ -1,5 +0,0 @@
| Endpoint | Description | Sample Java Code |
|-------|-------------|---------|
| {{matchdevice}} | Takes the incoming identifiers in the web request and looks to match those identifier values with any identifier values in existing profiles. The matching process is defined by the identifiers and rules configured in the ID service. If there is no match, a new profile is created. | {{matchdevice_sample_code_java}} |
| {{multiscreening}} | Returns a list of all device profiles that contain a specific first-party identifier, such as a login ID. | {{multiscreening_sample_code_java}} |
| {{household}} | Returns a list of all profiles containing a specific IP address identifier value. | {{household_sample_code_java}} |

24
_includes/reuse/hmac_security.md
View File

@ -1,24 +0,0 @@
## Configuring Security
To authorize your submission to each REST endpoint, AdTruth Resolve uses a keyed **H**ashing **M**essage **A**uthentication **C**ode (HMAC) algorithm. The role of HMAC is to do the following:
* Ensure the integrity of the message
* Verify authentication of the sender and receiver to the client
* Prevent replay attacks
The cryptographic strength of the HMAC depends upon the size of the secret key that is used. As such, the SHA-256 function is used to generate a 256-bit signature for the submitted text.
To use HMAC, you must produce an authentication header that includes a key that identifies who you are (API Account Key) and a hash that proves the message came from you and has not been modified (Signature).
In the sample implementation code, the Utility.java class (inside the `util` package) contains the necessary code for the HMAC security. See the following lines inside Utility.java:
```java
public static final String CLIENT_CODE = "12345";
public static final String SECRET_CODE = "zander";
```
You must change the values for the `CLIENT_CODE` and `SECRET_CODE` to the values supplied to you by your account representative. This is all that is required to configure HMAC to authorize your submission in the sample implementation. (The rest of the code in the class generates the SHA-256 value required for the authorization.)
Each of the REST endpoints uses the Utility class for HMAC authorization.
When you submit your request, an authorization element will be included in the header. This authorization header contains the client code along with a signature. The signature is generated using a unique value such as time, an IP address value, or other string that you hashed using HMAC-SHA256 along with the secret.

5
_includes/reuse/rest_response_abbreviations.md
View File

@ -1,5 +0,0 @@
| Abbreviation | Description
|--------------|-----------|--------|
| id | The profile ID. |
| ld | A list of identifiers — one entry per identifier type being tracked. As matches are made against the profile, the last ID value for each type is retained in this list. Each entry in the last ID list follows a <key: value> pair format. The key is the Code value for the identifier. The value is the identifier value, that is, the actual ID that was last seen for this identifier.|
| pr | Privacy preferences for the user. The first item in the privacy object is the privacy type. There are three options: `IOS` (apple privacy), `PC` (android privacy), and `DNT` (do not track). <br><br>Each of those options can have two sub-items: `au` (audit) and `cv` (content value.) Audit is the timestamp when the privacy preference was received, and the content value is the value of that privacy preference. The system can be configured to store multiple privacy preferences.|