couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saul Hazledine <>
Subject Authentication and Authorisation for webmail project
Date Mon, 20 Apr 2009 12:53:39 GMT

I've been writing a simple webmail system as part of a hobby project. This
is being done using Ext-JS talking JSON to a simple java servlet that runs
relational database queries. I always felt that a relational database was
overkill for what I wanted to do. I'm also aware that most of the logic on
the server side is there to convert from JSON to JDBC and back.

This weekend I discovered CouchDB. It does the same as the servlet I wrote
-- only faster, more elegantly and with replication. Its such a good match
it would be rude not to use it.

However, I've got a few questions about how to go about moving from Java
servlet relational database thinking to CouchDB . I'm happy to RTFM if given
the location of FM.

The first question concerns how to separate different email users. Would it
be OK to have a database for each user? This would make querying fast but I
was wondering about the overhead of having say, 1000 databases handled by 1
CouchDB instance. If its too high I could go the more obvious way of using
an index on a userid field and having a single database for all email.

The second question is regarding authentication and authorisation. One user
shouldn't be able to read, edit or delete another users email. I can't work
out how to do this with CouchDB unless I use some sort of proxy that would
check username and password against the view being accessed or the data
being written. If this is the only route to go can anybody recommend a
lightweight language/server to use for this? My first guess would be Java
servlets although this would make each access go through the following
  frontend webserver -> servlet engine -> couchdb
when ideally I'd want:
  frontend webserver -> couchdb
or in a perfect world:

Thanks in advance for any advice you can give.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message