The Datably Database Stack provides it's CRUD services without an access management system. This is by purposeful decision in order to make the frontend as user friendly as possible.
However, this requires you, the web developer, to take the necessary precautions for the safety and security of the database behind Datably.
In this section we are going to provide several suggestions to prevent abuse of this middleware.
Use Gatekeeper, our drop-in solution to secure a web-site.
It is the easiest way to protect your content. It works with
Time-Based One-Time Passwords, so you don't have to remember anything. All you need is an authenticator app or a Yubikey!
You can get it in a
bundle with Datably and save money.
Create two separate database users, one exclusively for reading data and another one which has read/write permissions.
Extend this scheme on to a by-table basis. This way you end up with a finely grained permissions system.
For this to work, you will have to create two pages inside your Stacks project - one for reading data and another on for CRUD operations.
sqlite3 does not have a permissions management system of any kind. Therefore, access management can only be done on the basis of file-based permissions. This means that on a Linux/UNIX based system, you have to set the file permissions for the user under which the web-server runs (e.g. www-data) to
r - - r - - r - - (444, read-only) if you want to turn off creating/updating/deleting datar w - r w - r - - (664) if you want to allow creating/updating/deleting data
For this to work, you will have to create two pages inside your Stacks project - one for reading data and another on for CRUD operations.
Use the Allowed Methods options in order to decide what end-users are allowed to do with this Database Middleware.
Create - If selected allows creation of new records
Update - If selected allows editing of existing records
Delete - If selected allows deleting of existing records
These options can be set individually. If none are selected, you have a read-only connection to your database.
Another way to secure your CRUD page is to implement user access on the web server via .htaccess. This provides a username/password protection of the entire site. If you want to have a public read-only site, you will have to create this separately and implement database-related read-only configuration as outlined in the "Database" section. A configuration guide for Apache 2 can be found here.
A reverse proxy provides FQDN based forwarding of requests. You can use this to steer users based on a particular host name to either the read-only site or to the CRUD site. A video about the basic configuration of Nginx as a reverse proxy can be found here.
The most thorough way to secure a CRUD page is to place it behind a firewall and there make it inaccessible to the public internet. Again, if you want to have a public read-only site, you will have to configure this separately and implement database-related read-only configuration as outlined in the "Database" section.
