Creating and Debugging Filters with Access Logger
Using the Access Logger¶
The access logger has two properties. One is for recording specific payloads to create routes, filters and operations on your payloads to be secured. The second property is recording traffic, status codes and showing you what requests are being made through VGS to and from your server.
Enabling the record function, will record traffic for 1 hour. During this time you can introspect on traffic and fine-tune your configurations.
To view the requests that were captured, after you’ve clicked record and sent data through, click ‘Load New Requests’ if it hasn’t populated. Recorded requests will show a little database icon to the left. Once you click an entry a pop-up showing you all the details of the payload (Headers and Body, Request and Response) will be viewable. Within this view, we have more context around the request, including headers, body, origin, etc. Right now you can see the Request Body with original ‘foo’ value being rewritten to ‘tok_dev_npuehSyKAsuFquDQ149QRw’.
From here we can select the payload we want to operate on and generate filters and a route for. From here we get the following options to Operate on our data. Redact/Reveal, Storage and Format.
If an error occurs while sending data, the access logs are an extremely useful tool. Here we have a 405 Method not allowed error.
Clicking on the item with the error status code reveals the full error message response and enables us to inspect the Request that caused the error.
In this case, this particular endpoint only allows for HEAD, OPTIONS, POST. Our request caused an error because it was a GET to a /post route.
Our access logs show the body of the payloads and the response messages. It is also useful for making sure headers, end-points, paths, etc. align with the filters set up.
While setting up filters you may need some insights whether filters’ conditions and operations are matched in requests - pay attention to Match Information section of General tab.
The additional functionality of the Access Logs is that in the Live environment and Sandbox environment you will see the most recent requests that traveled through VGS, their status codes, and the time of the action. This is useful for seeing which of your requests finished with good status codes, and those that have failed. These are distinct from the other requests that are recorded by their lack of the database icon.
- A 407 error, an authentication error, will prevent you from seeing an upstream response in your Access Logs because the request will terminate at our authentication check before going through our service.
- A 504 response will not produce an error code in the logger. Instead this means that our service was unable to connect to the destination on the outbound connection (e.g. no status code was returned)
- If you see a request and no response, it may mean that your request didn’t complete its route through the tunnel to its destination.
- If you don’t see anything on the Access Logs page (and logging is enabled) you’re not hitting the VGS service.
- The Access Logs also allows you to see what inbound data your server will receive and what outbound data third parties will see.
If you have any questions, comments or feedback on this guide contact us on our site chat or at firstname.lastname@example.org