Not one, but *two* new videos

It's been months since RDBHost added CORS support enabling cross-site AJAX requests, and even longer since we put the JavaScript module online for general use.

A few days ago, we put online a new video showing the complete process of creating a JavaScript app.  As online videos go, it is a tad long at 11 minutes plus, but it does cover the whole process.


If you think 11:25 is just too long for a video, we put up another shorter video.  It shows a few features of the Rdbhost database administration utility, RdbAdmin.



Link to JavaScript Video
Link to RdbAdmin Video
Link to Rdbhost.com

Host your database-backed site on GitHub, for free!

We could say, "Host your github page's database on Rdbhost, for free", and be equally correct.  But Github has a greater profile than we do, so they get first billing.

A database backed website is mostly in the database, but it cannot be done without some static content.  The styling and the code are in plain files, which you have to host somewhere behind an accessible url.   Rdbhost clients can server static content from the database, using plain urls, but you can reasonably want to host static content elsewhere.  Github.com is a very well known git repository host that can also serve web pages.  The web site is under your domain name, and the git repository hosting doubles as a handy deployment system for the site.

Github hosts the static pages, and Rdbhost hosts the database, for a database-backed web application at no cost¹.  We describe how to set this up, in some detail, here.

We have a demonstration online, at http://gh.rdbhost.com/threefaves , of a database-backed site hosted on github.  Three Faves is a little taste-association app, the simplest demonstration app I could think of that might be fun. The site content itself is in a public repository at https://github.com/rdbhost/rdbhost.github.com .   All coding is in the repo, in one file, there for you to read and copy.  The Rdbhost account white-lists SQL queries, so undesirable queries cannot be run against the threefaves account.

Links:
Rdbhost SQL Database Host
Threefaves Site
Threefaves Repo


¹ We say free, but that is qualified: Github will host non-private content for free, at apparently no volume limit; Rdbhost will host private or public data for free, but only at low volumes.

Minor gains

The Rdbadmin utility has been upgraded again.  I improve it from time to time, and sometimes I write aobut the changes.

A bug-fix corrected the problem that dropped schema names from function identifiers.  This proved to be a problem in managing the log trimming functions for our sql logging facility.

We also added comment displays to all the items of the table structure display, including indexes and constraints.  Only the table structure edit tool facilitates adding comments, but comments can be added to anything using SQL, like:

COMMENT ON INDEX idx_name IS 'this index is the primary key';

We have been adding comments to tables and other resources that Rdbhost creates in user accounts; When you go exploring existing tables using Rdbadmin, the comments displayed will help you, hopefully, understand how each resource was intended to serve.

SQL Logging, how mundane

When you're sending requests to a database, or to any online API, it can be useful to be able to tell what requests are getting through, and whether results are being sent back to your client.

Rdbhost accounts now have SQL query logging.  Each SQL query is stored in a table in your account, with arguments and contextual information.  The log table is in a separate schema (called 'monitor') to minimize name collisions with your data tables, but you can run queries against the log table just like any other table.  The page displaying recent queries is linked from the account profile page.

The logs are trimmed automatically, and you can redefine the trimming function to set your own criteria.

https://www.rdbhost.com/sqllogging.html

If you are unacquainted with Rdbhost, each account has one database, which can be accessed via a choice of client-side APIs, or from an administration program, RdbAdmin, that we host.

A post about Authentication

At Rdbhost, there are passwords, and there are 'authcodes'.  What is the difference?

Passwords are about 30 characters or less, memorable, and submitted with an email address as a login.  The email/password login process is back-stopped by failure counters, that inhibit a brute force attack on the password by requiring increasing delays between tries.

Authcodes are 50 characters, base-64 character set, that are randomly generated and assigned to the account.  Machine requests to the database are submitted with a role name and an authcode.  There is a failure counting here, too, but for performance reasons there are multiple counters distributed around and they don't max out simultaneously, and the tolerated failure count for each is fairly high.  The authcodes are fairly resistant to 'social engineering' type attacks, as nobody chose them and there is little reason to remember them.  They get embedded in code, and forgotten.

Two roles have authcodes, and two do not.  Other than the super role, only the auth role has an authcode.

The auth role is different from the super role in that it can only run white-listed queries, and a given white-listed query can be restricted to only run for that particular role.  Since the auth role requires authentication, you can restrict its use to certain prequalified users, and give the role more Postgres privileges and its white-listed queries more power.

There has always been a way to change passwords, and now there is a way to reset authcodes, meaning to replace one with a new random authcode.

https://www.rdbhost.com/roles.html

More Backup Options

This week, Rdbhost has upgraded its bulk data transfer tools to be able to save the database dump to Amazon's S3 service, and to restore from same.

The additions are found on the Bulk Transfer page, which is in the left-hand menu bar on most membership pages.  There is an S3 configuration page, which askes for the access-key and secret-key, and the name of the bucket to store to.  The transfer to S3 page itself will save to an object named for the account, something like 'rdbhost0000000002' for account 2.  The S3 to rdbhost transfer asks for the object name.

The intended purpose for the tool is safe-keeping of snapshots of your database, for restoration in the case of data loss, but it is also useful for transferring databases quickly from one account to another.

The bulk transfer server uses streaming data flows (for all bulk transfers, not just S3), so no temporary copies of the dump are made anywhere, and the largest databases can be transferred.  The server will open up to five simultaneous transfers to accelerate the data flow to S3, so the S3 backup will presumably be faster than saving to the browser, though we have not measured the improvement.

You do need an Amazon Web Services Account (see aws.amazon.com), before you can use this streaming to S3 service, and you should create a bucket to receive the object.  We only create the object and put the data in it; the bucket must pre-exist. 

https://www.rdbhost.com/bulktransfer.html

Update for RdbAdmin

The RdbAdmin utility has been updated.  This is the 3rd major revision, and adds quite a few nice features.

New features:

• Supports use of back and forward buttons within the app.  This was implemented using the sammy.js library.
• Breadcrumb display to assist navigation.
• New Function editor
• New Trigger editor, linked from the table structure page.
• Record Editing forms now include table and column comments; when adding or editing a record, you can see how the table owner described each field.
• Record editing now supports a null checkbox for making value NULL.
• Most forms (all except SQL-command) support dynamic display of SQL generated.  As you fill in the form, you can see what SQL RdbAdmin will generate to change the database when you submit the form.
• Most forms have an edit option, so that dynamically generated SQL can be edited in the SQL-command form.  So if you need your query to include options not provided by the form, you can 'rough-in' the necessary query using the form, and fine-tune it by editing in the SQL-command form prior to submitting.
• Most forms have an 'add query to lookup.queries' link that will display the record-insert form, with the dynamic SQL from the previous form pre-loaded into the record form.  When you have a query perfected and tested, you can add it to the lookup.queries table in one step.  The lookup.queries table enables your script to execute queries by keyword, and invoke queries using roles that cannot execute free-form queries directly.
• In various forms interface now enables and disables buttons depending on relevance.
• The '** keep same **' option in record-edit type lists is now gone, replaced by relevant custom type name.
• In select panel, records are editable whenever a suitable index is available to uniquely identify unique records.
• You cannot see this, but most classes have been refactored to make private attributes genuinely private, and minimize the number of global variables.

Todo:

• Restore syntax highlighting; Previously, it previously used CodeMirror, but I had intermittent problems with code dependencies not getting defined.
• Add type editing tool, for creating and modifying custom types.

Links:
Github repository
Sample Account

.