Introduction
When managing databases, one is in the need to configure mechanisms of authentication which can extend to authorization mechanisms. RethinkDB has a plain simple users mechanism to control user creation, permissions given and scope of action.
In this tutorial you will apply several configurations of permissions to three different users.
Requeriments
- Have one server with RethinkDB running.
Setting things up
This administrative task is done via web panel. So after ssh login to your dopplet run rethinkdb
or rethinkdb --bind all
depending if you are tunneling or not so you can access your panel via domain_name:8080
or dopplet_url:8080
. Everything is done in the Data Explorer
section placed in the navbar.
RethinkDB makes you the admin
user when accessing it via web panel, so you have total control of the node.
Adding users
To avoid confusion between examples we are going to have several users, one per example. Users are stored in the table users
in the rethinkdb
database. To create them you use the insert
function passing a JSON object, to finish this step you are going to pass a JSON array of 3 members like this:
r.db('rethinkdb').table('users').insert([
{id: 'john', password: 'pass1'},
{id: 'jack', password: 'pass2'},
{id: 'joe', password: 'pass3'},
])
If everything went ok, you will get as response an object like this:
{
"deleted": 0 ,
"errors": 0 ,
"inserted": 3 ,
"replaced": 0 ,
"skipped": 0 ,
"unchanged": 0
}
It is important to note that once created you cannot modify the id
of the users, you have to delete the entire user so you can add it again with the desired name.
Adding tables
To encapsulate the tests you are adding two tables into test
database, CompactCameras
and DslrCameras
, you are executing two times the create method:
r.db('test').tableCreate('CompactCameras')
r.db('test').tableCreate('DslrCameras')
If everything went fine, you will get as response one medium sized JSON object telling you the details of each table.
With this you are ready to jump to the examples.
Example 1
In this example john
gets to read and write from the table CompactCameras
with the help of the grant
method:
r.db('test').table('CompactCameras').grant('john', {read: true, write: true});
After executing this command you will get an answer like this:
"granted": 1 ,
"permissions_changes": [
{
"new_val": {
"read": true ,
"write": true
} ,
"old_val": null
}
]
It is telling that permissions have gotten changes. It is also reporting the state of the configuration between old_val
and new_val
.
There is not anything left to do for configuring permission to this user, you could go and use this user in your application's authentication and everything would be working. Now you can review the second example.
Example 2
In this example jack
gets to read and write from the table CompactCameras
and read from DslrCameras
, seeing the last example you can infer that you have to execute the command two times,each for every table to modify:
r.db('test').table('CompactCameras').grant('jack', {read: true, write: true});
r.db('test').table('DslrCameras').grant('jack', {read: true});
You will get one response as the one from example 1 telling you the changes that have been done. The important thing in this example is that one user can have active permissions on different elements at the same time.
Example 3
In this example joe
gets access to all configurations of test
database with the exception of DslrCameras
, again you have to execute each command separately:
r.db('test').grant('joe', {read: true, write: true});
r.db('test').table('DslrCameras').grant('joe', {read: false, write: false});
The first thing to note in this example is that the grant
command can be applied to any level of the structure, where the levels are: r
as all the database, r.db
as one database and r.db.table
as one table in one database.
The second thing to note is that permissions in broader scopes get inherited to smaller scopes, using example 3 for this leads to say that joe
have read and write access to any element in test
database until it is specified that he cannot do it in the table DslrCameras
. There is one example left.
Example 4
Any global permission must be written directly to r
such as letting joe
full access to the server with the following:
r.grant('joe', {read: true, write: true, config: true, connect: true});
The last thing to note is that the connect
option is only eligible for global scope.
Conclusion
When a user is added it does not have any permissions, but you can set values with the grant
method, after that permissions not set are considered as false. The simplicity of RethinkDB does not let us to login to the admin panel as any of the users created in this tutorial, then the next step would be to create an app that connects to your server so you can test your user permissions. You can go and check the official RethinkDB and see the offering of drivers for your programming language of choice.
Top comments (0)