Our inbound connection uses an inbound/reverse proxy.
The most succinct definition we’ve found on what a proxy does is from Postman
The proxy can reside on your local machine, somewhere in your network, or at any point between your client and the destination server on the internet.
Similar to the way parents might speak to each other through a child, the child is a proxy relaying all communications between the 2 parents.
Parent 1: Ask your father if he can pick you up after school.
Timmy: Can you pick me up after school.
Parent 2: Yeah.
Timmy: Dad says yeah.
In this analogy, the child forwards the information on behalf of each parent. Besides just relaying information, proxies can do much more.
- Record all traffic between your machine and the internet
- Reveal the contents of all requests, responses, cookies, and headers
- Route traffic to specified internet locations
- Security from direct attacks.
The difference between our outbound proxy and our inbound is that the inbound is static and sits between your client side and your server side, while the outbound proxy sits between your server and third parties
What does it allow you to do?¶
- Rewrite requests or responses on the fly before data enters or leaves your system.
- Operate on data outside of the scope of your backend systems.
- Set/Change/Strip Headers.
- Modify the payload even if it’s not a strict redaction/replacement.
How does it work?¶
- You point your client API or Frontend to our reverse proxy and set the upstream in our dashboard to your server DNS.
- BEFORE: client.foo.com → server.foo.com
- AFTER: client.foo.com → tenantid.sandbox.verygoodproxy.com → server.foo.com
- ALTERNATIVELY: you can load your client website/app through the proxy. This is useful if your client and backend do not communicate via API. We can provide a CNAME to whitelabel this when you’re ready to use for production.
The inbound/reverse proxy directs traffic between the client-side (inbound) traffic, the VGS vault (where sensitive data is stored), and your backend systems as illustrated by the below image.
How do I implement it?¶
Let’s take the easiest use case, an HTML form posting credit card data. You can serve your content via the proxy https://
HTML <!--HTML--> <form class="form-horizontal2 boxed" method="post" action="/post"> <!--CREDIT CARD PAYMENT--> <div class="panel panel-info"> <div class="form-group"> <div class="col-md-12"> <label for="pan_number" id="pan_number_label">Credit Card Number</label> <input class="form-control" placeholder="Card Number" type="text" name="cc_number" id="pan_number" value=""> </div> </div> <div class="form-group"> <label for="pan_exp" id="pan_exp_label">CC Expiration</label> <input class="form-control" placeholder="Card Expiration" type="text" name="cc_exp" id="pan_exp"> </div> </div> <div class="form-group"> <label for="pan_cvv" id="pan_cvv_label">CC CVV</label> <input class="form-control" placeholder="CVV" type="text" name="cc_cvv" id="pan_cvv" value=""> </div> <div class="form-group"> <span>Pay securely using your credit card</span> </div> <button type="submit">Place Order</button> </form>
In this example form, on any press of the submit button we post to the path in the action attribute in the form tag:
In order for the form to relay to your server, just change your upstream to server.foo.com in the like the image below.
Once you have this set-up you can work on your transformers and filters.
VGS supports encryption to protect communications between VGS and your web application. VGS supports the TLS cryptographic protocol. Support for anything less than TLS1.2 is officially deprecated.
For more information regarding TLS:
If you need any help contact us on site chat or email@example.com.