Rdbhdb, now for Python 3

Our DB API 2 module, called Rdbhdb, now suppports Python 3.


In the process of updating, I found a good new module.

The Python 2 version used the 'encode' module from the Poster package.  That module has not been ported to Python 3, so I went looking for a new module to do multipart form-data encoding.  I found the Requests package on PyPI, and borrowed the 'filepost' module from that.  It works well.  In my search, I had opportunity to look over the Requests API, and it is an elegant API, doing the http request functionality in straightforward ways.  If I were writing my own module now, I would use Requests, in lieu of HttpLib/Urllib as I did.


Back to Rdbhost: the new Rdbhdb module is in the same Github repository as the old, where the two are seperated into different folders.  Each is complete, with setup.py and test suite.


David Keeney

https://github.com/rdbhost/Rdbhdb
http://www.rdbhost.com
https://www.rdbhost.com/howpython.html
.

Boilerplate

Rdbhost is a tool for getting simple web apps going quickly.

In support of that position, we now have boilerplate bundles; these are downloadable zip files that can be unzipped to your harddrive, and immediately function as simple applications.  Your account information is already embedded in each, so it will just run, and access your Rdbhost account as necessary.

The wizard collects from you the necessary information to create the boilerplate bundle.  After the wizard completes, you can download the relevant bundles from the boilerplate page; each includes a README.txt with starter instructions.


For now, there are as many as three boilerplate bundles, depending on your wizard selections; one for the Python Rdbhdb module, one for Python's SQLObject, and one for a JavaScript web app.  There will be more, in time, including options for html boilerplate, and these (especially the JavaScript bundle) will be enhanced.

Try them out, let me know if they don't behave as expected.

David Keeney
dkeeney@rdbhost.com

running Credit Card Charges for Rdbhost Applications.

More and more types of services that once were exclusively 'server-side' on your web-server, are now independently hosted web services, accessible via a web API.

One such task is handling credit card charges; Stripe.com handles credit card processing through a web API.  Rdbhost now supports handling charges for your hosted web application via Stripe.com.  This is the second web-service we support, after email.

This service works similarly to the email mode, in that a query pulls the input data for the charge, including CC Num, CCV, expiration, etc, formulates a Stripe request from it, submits it, retrieves the result from Stripe, calls a database function to store the result, and then returns a summary status record to the client, via the selected data format.  Any or all of the results of the initial query can be concealed from the client, for customer privacy and security reasons.

CC Charging uses a new mode, called 'charge'.  Each record returned by the submitted query must contain a certain set of fields, to include 'ccnum', 'amt', 'apikey', 'service' and 'currency'. One charge is run for each such record.

Since the actual charging is done by a third party email web-service, you need to set up an account on stripe.com; they will provide you the API key.

The result page is formatted just as the result page for email mode, with either 'success' or an error message for each record processed.


jQuery Rdbhost Plugin

The jQuery plugin does not have any specific methods for charging, but the $.postData method will suffice, and the example linked below shows how to use it that way.  This example only relies on database storage for the api key, as that needs protecting from the end user.

Example Payment Page
Rdbhost Documentation on Charge Feature

and Now Email, too

Toward our goal of making Rdbhost.com a universal backend, suitable for supporting a wide range of websites with no custom server-side coding, we have taken a large step in adding emailing capability.

Now, clients can send email through a query request, without Rdbhost disclosing to the client who the recipients are. This can be useful in implementing password recovery systems and initial password emails, for example.

The implementation is in the form of a new mode, called 'email'. The Rdbhost request protocol has a new parameter called 'mode'.  The default mode is to just send the query results to the client.  For other modes, there will be some intermediate step that takes the query results, does something, and returns another set of results.  The first such mode to be implemented is email.  The query results are input to the emailer, and the success/failure status of each email attempt is returned as the result to the client.

Each record returned by the submitted query must contain a certain set of fields, to include 'To:', 'From:', 'apikey', 'service' and 'body'. One email is sent for each such record.

The actual emailing is done by a third party email webservice of your choice. So far, we support postmarkapp.com and emailyak.com. The 'service' field indicates which service you are using, and 'apikey' must contain the corresponding API key. Before using email on Rdbhost, you must set up an account on one of those services; they will provide you the API key.

A very simple 'proof of function' email query might look like:

SELECT 'me@example.com' AS "From:",
       'you@example2.com' AS "To:",
       'abcd12345xyz' AS "apikey", 
       'yak' AS "service",
       'test message' AS "Subject:",
       1 AS "Idx",
       'Test from Rdbhost.\nHey there' AS "body";

This will send one email to 'you@example2.com'.

The preceding example revealed the API key as well as the to: address. If you were to use this query verbatim, you would want to use keyword lookup and restrict it to white-listed roles (Preauth or Auth), to prevent the API Key from being disclosed. You would also need to deny SELECT priv to the reader role to the lookup table, to keep the query from being read.

This is a bit of trouble, and constrains other uses of the lookup table. It would be easier to just move the private elements out of the query statement into tables, and restrict access to those tables.

A more typical query might look like:

SELECT cust.email AS "To:",
      'me@example.com' AS "From:",
      'news this week' AS "Subject:",
      api.apikey AS "apikey",
      'yak' AS "service",
      tpl.body AS "body",
      cust.id AS "Idx"
 FROM customers AS cust, 
      email_service_info AS api, 
      email_templates AS tpl
WHERE email_templates.type = 'weeklynews';

This would send the contents of email_templates.body to each customer in the customers table.

After the emailng is complete, a page body is sent to the client indicating the apparent success or failure of the emailing. The page is in json or xml format, and conveys a list of email send events, each entry including a unique key and 'Success' or an error code as returned by their API. The preferred page format is specified as the format parameter..

The resulting page, in json, would resemble:

{
    "records": {
        "header": [
            [
                23, 
                "idx"
            ], 
            [
                705, 
                "result"
            ]
        ], 
        "rows": [
            [
                2, 
                "Success"
            ]
        ]
    }, 
    "row_count": [
        1, 
        "1 Rows Affected"
    ], 
    "status": [
        "complete", 
        "OK"
    ]
}

Be aware that this only reports immediate errors from the API. If the recipient address is bad, that will not be known until later, and you would need to use the email service's own reporting pages to evaluate that.

jQuery Rdbhost Plugin

The jQuery plugin does not have any specific methods for emailing, but the $.postData method will suffice, and the example linked below shows how to use it that way.  This example only relies on database storage for the api key, as that needs protecting from the end user.  Your applications may well retrieve From or To addresses from a database as well.  The example application cannot be used to send spam to arbitrary addresses, as the recipient is hard-coded into the query, and the query itself is white-listed (variants will not pass the white-list).

Example Emailing Page
Rdbhost Documentation on Emailing Feature

OpenID logins

Third party user authentication is popular these days.  This allows you to use one login id with multiple websites.

You may want to use OpenId with your Rdbhost backed website, to give your users the convenience of using their single-login.  OpenId is one of the two widely used third pary authentication protocols.

We have added OpenId verification to our API.  You can invite your users to login using OpenId, present that login request to the Rdbhost server using the JavaScript API, and the server will handle the verification process and return the outcome to you, along with a session key (if authenticated) for that user to access your database services.  Note that this session key is just a key for use in authenticating a user, or authorizing database access; coding the key-based constraints is an app design issue.

Third party login is quite appealing to users, and seems to be becoming an expected feature of new web apps.  We are happy to support this for your Rdbhost hosted apps.

OpenID login is enabled from your profile page on the Rdbhost website.  When the feature is enabled, a new schema 'auth' is created, a simple user tracking table is created there, and a PL/pgSQL database procedure is created for you to handle OpenID logins.  You can override this procedure with your own, to implement custom login handling.

An example is at:
http://www.paginaswww.com/rdb/examples/openid-login.html

and details are at:
http://www.rdbhost.com/openid_login.html

The jQuery plugin has been updated as well, to support OpenID logins:
http://github.com/rdbhost/Rdb.js

Javascript API made easier; no domain management required

The javascript API library for Rdbhost has been updated, and is now even easier to use to access Rdbhost hosted databases from your javascript application. No longer do you need to to set up a domain pointer from a subdomain of your site domain to the rdbhost server.

 Just include the new jquery.rdbhost.exdm.js module in your page, pass your account role and authcode to the $.rdbhostConfig call, and use the provided methods to access your Rdbhost database; the library includes both an SQLEngine class with query methods, and also a jQuery plugin that applies query results to selected element sets.

 The jquery.rdbhost.exdm.js module is based on Oyvind Kinsey's easy-xdm library, which uses a variety of inter-domain messaging techniques to enable returning data from the Rdbhost server to your page on any domain. We do apply CORS domain-checking to prevent unauthorized cross-domain access, but the default CORS authorization provided for new accounts is the wildcard '*' permitting all domains, including localhost. When you finish the app and move it to a public server, specify the domain as a remote host in Rdbhost website management page.

The module is at: https://github.com/rdbhost/Rdb.Js

There are example pages for various API methods at: http://www.paginaswww.com/rdb/examples

The jQuery plugin has been extended to support OpenID logins, as well:
http://github.com/rdbhost/Rdb.js