Universal Proxy

Your application is on the client, and RdbHost provides back-end database service. All the business logic is in the client-side JavaScript, with limited security-oriented logic in SQL.

The proxy mode allows you to pull private data from a table, send it (with appropriate public or user data) to a third party web-service, and relay the results of that web-service to the client.

The main limitation of building apps in this client-side-only JavaScript is that it is impossible to hide in the source code things that should be hidden. [show source] will reveal all. Some things, like web-service API-Keys need to be hidden, to avoid anonymous users salvaging and misusing the keys.

We have been providing features to enable specific classes of server-side functionality, specifically credit-card processing and emailing, to work around that limitation. These features allow you to keep the privileged items, such as API-Keys, in restricted tables, pull them in a query to supply the 3rd party web-service, and returning to the client only the outcome of that web-service. The private table data can serve an anonymous user, without being revealed to that user.

We provide specific services, via the 'email' and 'charge' modes, to handle emailing and credit-card charging. It is generally more useful to use those modes in lieu of this generic proxy wherever they apply. Use this service to access web (http[s]) sites and services from the RdbHost server where the specific services do not apply.

Sending a proxy request is done like any RdbHost request, with the same API calls, but with "mode='proxy'". The SQL of the request will pull one or more records, each with the following four columns:

category, idx, name, value

Columns

category
one of these values: 'url', 'auth', 'pragma', 'header', 'field', 'file', 'body'. VARCHAR

idx
a label, type VARCHAR, can be NULL

name
meaning depends on category, see table below. name is VARCHAR, value can be TEXT or BYTEA.

value
meaning depends on category, see table below. name is VARCHAR, value can be TEXT or BYTEA.
category idx name value
url Null 'GET' | 'POST' | 'PUT' | 'OPTIONS' | 'PATCH' | 'DELETE' url ex: https://api.twitter.com
auth Null _login password
header Null header-name header-value
pragma Null allow-redirects [True] | False
pragma Null form-encoding 'url' | ['form']
pragma Null postcall SQL query
pragma Null errcall SQL query
pragma Null timeout number
pragma Null ssl-verify True | [False]
field request id parameter name parameter value
file request id file name file body
body request id Null raw body content

The only required record is the url. There can be only one url and one auth record, the others can be duplicated. There can be only one of each pragma, and only one of each header.

The request id is a VARCHAR. file and field values are grouped by their request ids. Each group is used for one request to the web-service, so multiple proxied requests can be made with one submission to RdbHost, by providing each group of fields and files a unique label. For the typical case of one proxy request per submission, the request id can be Null. All pragmas and all headers are used for each proxied request.

postcall and errcall are SQL queries that get executed after successful and unsuccessful requests, respectively. There are tokens '{SOURCE}' and '{RESULTS}' that can be used in the query; they will be replaced with the source data as a json string, and the actual response body from the web-service. errcall always gets a plain string for '{RESULTS}', carrying the name of the error.

Mode Parameter

The request-proxying mode is requested with the mode parameter, using the value 'proxy'.

A query example:

SELECT 'url' as "cat", NULL as "idx", 'GET' as "name", 'http://httpbin.org/json' as "value";
          

This query, submitted to rdbhost.com with a mode='proxy', would result in the json page at httbin.org being retrieved. The content returned to the client would be the page itself, wrapped in the usual RdbHost JSON status, records, rows structure.

We can make the above example a little fancier like:

  SELECT 'url' AS "cat", NULL AS "idx", 'GET' AS "name", 'http://httpbin.org/json' AS "value"
UNION
  SELECT 'pragma', NULL, 'postcall',
                         'INSERT INTO "logtable" (page) VALUES({RESULTS}); SELECT {RESULTS}';
          

This version would get the json page, insert it into a "logtable" table, and return the page, as above. Whenever a postcall or errcall query is executed, the results of that query is returned as the page. When there is no postcall or errcall query, the retrieved page is returned instead.

There are two named values that can be passed to the 'postcall' or 'errcall': '{RESULTS}' and '{SOURCE}'. {SOURCE} gets the request itself as a json string, and {RESULTS} is the raw result of the proxied request, in whatever form was requested, be that JSON, XML, etc..

See more Proxy Examples.