admin accounts and server secret

[gr2m]

We nearly removed usage of any CouchDB APIs which are not directly implemented by PouchDB. We now keep track of database and continuous replications created by an app ourselves in a custom hoodie-store database, it’s been all implemented via https://github.com/hoodiehq/hoodie-store-server/pull/45.

The last two APIs that we currently use where the usage of PouchDB and CouchDB diverge are

1. server secret
2. admin accounts

With both these changes, we would also become fully compatible with other CouchDB-like providers like Cloudant and could share one CouchDB among many Hoodie apps which might be helpful for hosting providers.

server secret

The server secret is used to generate and validate session IDs. If CouchDB is used as the backend, we load the server secret from GET /_config/couch_httpd_auth. That makes the session we currently generate in theory directly compatible with the ones CouchDB would generate itself for a given document stored in the _users database. But I can’t think of a use case why this would be useful and besides Hoodie does not require the special behavior of the _users database, it can save its account in any custom database. The name is already configurable.

I would instead suggest we create another database similar to hoodie-store, maybe hoodie-config, in which we store configuration like the server secret. That we we don’t need to differentiate between PouchDB and CouchDB any longer, we would simply get a PouchDB instance which we would use to create the hoodie-config database unless it already exists and create or read out the current server secret upon initialisation.

admin accounts

We currently treat CouchDB admins as the admins of the app. I came to the conclusion that this is not a good idea. Just like other database systems we should differentiate between the credentials used to connect to the database and the user or admin accounts that get created for the app. I should be able to change my CouchDB’s admin credentials without affecting my app and vice versa (besides adapting configuration).

It would also make the implementation of the Hoodie Account Server much simpler. We currently need to look at two places when validating a session id:

1. configuration which holds admin accounts
2. user account database

This leads to implementations like these which are complex and probably not very performent. There are also other differentiations between user and admin accounts that have to be handled at many places. For example admin accounts don’t have any other properties than the username and a password, as there are no documents for them in a database.

I would recommend to store both user accounts and admin accounts in the same database and simply differentiate them with a role property hoodie-admin.

[gr2m]

An alternative for admin accounts would be to entirely remove all routes for admins from @hoodie/account-server and instead move them to @hoodie/admin. And store user accounts and admin accounts in two different databases.

[gr2m]

As I explore the implementation of the ideas mention above in https://github.com/hoodiehq/hoodie-server/pull/526, I realise that I think a good first step would be this

1. store server secret in a hoodie-config/hoodie (hoodie-config database, document with _id hoodie, in secret property
2. Make the admin password an option to be passed to hoodie. We won’t support multiple admins anytime soon anyway, so the only thing relevant at this point is the admin password. The current implementation uses the CouchDB config for that, and for PouchDB the admin password is simply set to secret, which is not a good idea anyway. So I would suggest we add the admin password option for now, we could make the postinstall hook that currently sets the "start" script in the package.json to also create a .hoodierc file with a random password unless it is already set. Later, we could do something similar like CouchDB’s "admin party", not in a sense that everyone user can do anything, but that the first visit to /hoodie/admin will prompt the user to set an admin password, which then will be stored in the database.

[janl]

post-merge +1 ;)

We only had CouchDB-admins because we were depending on being able to use /_config, which only admins can do.

We are no longer depending on _config, so this is a welcome simplification.