1

I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?

Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...

gekko42
  • 368
  • 3
  • 14

2 Answers2

0

You could do it either way. First about couchdb users

  • Users in couchdb are stored in a special _users database

  • Database permissions are handled by a special _security document. This is specific to every database.

  • In security documents you add users that you have already stored in the _users database previously.

So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.

Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:

  1. Store your "business logic users" in the special _users database.
  2. Authenticate it with the _session endpoint.
  3. Extract the cookie header and sent it with your application headers.

All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.

If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.

The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.

Akshat Jiwan Sharma
  • 15,430
  • 13
  • 50
  • 60
0

If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store

It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.

It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.

A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules

The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.

You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.

giowild
  • 479
  • 5
  • 17