{"id":175,"date":"2021-05-11T00:41:31","date_gmt":"2021-05-11T00:41:31","guid":{"rendered":"http:\/\/iplocationblock.test\/codex\/validation-logs\/"},"modified":"2021-05-11T11:55:32","modified_gmt":"2021-05-11T11:55:32","slug":"validation-logs","status":"publish","type":"codex","link":"https:\/\/iplocationblock.com\/codex\/validation-logs\/","title":{"rendered":"Validation logs"},"content":{"rendered":"

This plugin stores validation logs when Record \u201cLogs\u201d<\/strong> is enabled in Privacy and record settings<\/strong><\/a> section on Settings<\/strong> tab.<\/p>\n

<\/p>\n

Contents in log<\/h3>\n

\"Validation<\/p>\n

The followings are some of items that are stores in logs.<\/p>\n

Request<\/h4>\n

Following the HTTP method and the port, the requested path is recorded. RFC2616<\/a> (obsoleted by RFC7231<\/a>) defines 8 method, i.e. GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT. The definitions says:<\/p>\n

\n

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered \u201csafe\u201d. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.<\/p>\n<\/blockquote>\n

But in the real world, we can find a simple hyperlink (i.e. GET method) which takes an action other than retrieval.<\/p>\n

\"Media<\/p>\n

Anyway, we\u2019d better take care about what\u2019s being done by a malicious request.<\/p>\n

$_POST data<\/h4>\n

When a request submitted by POST method is blocked, keys in $_POST<\/code> environment variable are recorded into the log. The corresponded keys in \u201c$_POST keys to be recorded with their values in logs<\/strong>\u201d in Privacy and record settings<\/strong><\/a> section are deployed to their values in order to take a look at them.<\/p>\n

\"Record<\/p>\n

The recommended keys are as follows:<\/p>\n