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

.