Access Logger

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. enable-access-logger

Viewing Payloads

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. list-all-requests 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. view-request-details Within this view, we have more context around the request, including headers, body, origin, etc. view-request-details 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. secure-payload-request From here we get the following options to Operate on our data. Redact/Reveal, Storage and Format. operation-options

Debugging

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. view-405-status-logger

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. see-response-logger-general see-response-logger-headers see-response-logger-body

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. match-information

Access Logs

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. access-logs

Request pin/unpin mechanism

To enhance the debugging experience for our internal and external users, we have added and expanded the existing functionality of Access Logs and implemented pin/unpin mechanism.

Access Logs help to debug issues with routes configuration, however, their lifetime is short: 24h for logs, 1h for a log with the payload. From now, there is a possibility to save the needed requests and reproduce the issue/test scenario without a fear to lose the context.

Pin/Unpin mechanism allows to:

  • Pin a request with or without the payload
  • Unpin a request from the table
  • Filter by pinned only requestspin-request

Pin Request restrictions:

  • Pin Request works on the Sandbox environment only, as Live payload contains sensitive data
  • Maximum 50 requests can be pinned at the same time
  • Pinned requests are kept for 90 days or until they are unpinned

Download logs

For performing a more detailed analysis of your requests and applying more advanced filtering, use the download logs feature.

Downloaded logs restrictions:

  • Last 24 hours
  • Last 10 000 requests
  • Payloads can’t be downloaded

Data format: JSONdownload-logs

Tips

  • 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 support@verygoodsecurity.com