Authentication with username/passsword

[nikarh]

Hi, it seems that it is currently not possible to connect to rethinkdb providing username and password. Since authKey is not present in the latest version of rethinkdb, the only way to get this proxy working with db is leaving db unsecured.

[coffenbacher]

Neither username / password or authKey should be used to secure rethinkdb from unwanted connections in the first place.

Leaving the db "unsecured" is correct and required - you need to use other tools (firewall / SSH tunnel / VPN / whatever) to restrict the "unsecured" access to only your machines. https://www.rethinkdb.com/docs/security/

I don't think there's anything this library needs to support here, as far as I can tell.

[mikemintz]

I agree with @coffenbacher answer: relying on authKey or username/password to secure the connection to the db is not recommended.

However, if someone has a use case, e.g. connecting to an existing database that happens to require username/password, I'm happy to accept PR that adds this functionality.

[babakness]

Looks like RethinkDB is in full swing again! 🎉

https://news.ycombinator.com/item?id=13579544

Ok, so I'd like to make a PR here but I'd like some guidance on what's going on. I tried hard coding a user/password here (for testing purposes)

https://github.com/mikemintz/rethinkdb-websocket-server/blob/master/src/Connection.js#L33

I hard code this in:

 let options = {
   host: dbHost,
   port: dbPort,
   user: 'does_not_exist',
 };
 console.log(options)

When I run the code, I see the options are set as hardcoded, yet I am to query RethinkDB as if I am connected as admin. We need to access RethinkDB as a controlled user with specific permissions. Password isn't the issue where, permissions are.

Suggestions welcomed.

[mikemintz]

@babakness I'm not sure exactly what's happening, but you should be aware there are often two connections:

1. a proxied connection from the browser via rethinkdb-websocket-server to rethinkdb (which is the one it looks like you've hardcoded a user for)

2. a connection directly from your backend app that you'll see in all examples for doing permissions (e.g. rethinkConn in involved example in README)

Are you sure what you're seeing is from the right connection?

[babakness]

Hey Mike, I see that, I'm doing the most basic thing. Hopefully this deeper explanation of the situation is helpful.

var express = require('express');
var http = require('http');
var RethinkdbWebsocketServer = require('rethinkdb-websocket-server');

var app = express();
app.use('/', express.static('assets'));
var httpServer = http.createServer(app);

RethinkdbWebsocketServer.listen({
	httpServer: httpServer,
	httpPath: '/',
	dbHost: 'localhost',
	dbPort: 28015,
	unsafelyAllowAnyQuery: true,
});

// Start the HTTP server on port 8015
const port = 3030;
httpServer.listen(port);
console.log(`Server started on port ${port}`);

So I can see the output from console.log in my example above

 let options = {
   host: dbHost,
   port: dbPort,
   user: 'does_not_exist',
 };
 console.log(options)

This is connecting to localhost here

https://github.com/mikemintz/rethinkdb-websocket-server/blob/master/src/Connection.js#L43

(Commenting out this line prevents connection). Is this line the last step before connecting to the given host/port? It seems that user in the option above makes no difference.

[mikemintz]

So in order to implement this, we would have to modify the the client handshake to include authentication details.

Here are some references:

• Current rethinkdb-websocket-server client handshake code
• Official rethinkdb javascript driver handshake code that deals with authentication
• Rethinkdb documentation on writing client drivers

I think that since rethinkdb-websocket-server currently uses V0_4 and authentication was only added as of V1_0, it'll be a bit more work than just adding the authentication field.

[babakness]

Hey Mike,

Interesting discovery:

If I remove /node_modules/rethinkdb-websocket-server/node_modules/rethinkdb/net.js of course the server doesn't work. However, if remove all the code in this file and just replace the entire thing with console.log('from net.js'). I receive the message "from net.js" and connections from a remote websocket work without issue.

By the way, when you say V0_4, I'm confused what you mean? The package.json from rethinkdb-websocket-server states "rethinkdb": "^2.3.0", Where is V0_4?

Thanks.

[mikemintz]

I feel like that net.js file shouldn't affect proxied connections. Are you saying that authentication works when you do this?

Regarding V0_4 vs V1_0, those are protocol versions. Take a look at https://www.rethinkdb.com/docs/writing-drivers/ and ctrl-f for V0_4

[babakness]

No, but the linked file

https://github.com/rethinkdb/rethinkdb/blob/next/drivers/javascript/net.coffee#L1007-L1021

Is to what compiles to net.js right? When I comment all the code in net.coffee and compile, it surprising connects, not with authenticated user but it works. So I'm confused how this file has the authentication data to connect to RethinkDB but completely removing all comments still manages to connect. Like, what does it even do in V0_4? At least in my connection setup.

BTW, has much changed from V0_4 to V1_0? Maybe it will just work?

I really like this setup. I think the isomorphic queries are great and the query whitelisting is just brilliant. This is what Horizon should have been. The only issue is that even when prototyping, its nice to be able to leave "unsafelyallow..." to true when building but at least know that the permissions aren't root or admin level, just in case.

[mikemintz]

I don't think it's too surprising that it works without net.coffee, since that should only be used when rethinkdb-websocket-server makes a direct rethinkdb connection. The proxy connections use net.coffee in the browser, but get converted from websocket to TCP without much introspection (other than the parser written in rethinkdb-websocket-server for query auth).

I haven't looked much into what's changed from V0_4 to V1_0. I think it's mostly the connection handshake, and the rest is mainly backwards compatible.