couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Mitchell <>
Subject Re: Introducing Bram Neijt
Date Tue, 26 Oct 2010 16:24:08 GMT
On Tue, Oct 26, 2010 at 10:48, Jan Lehnardt <> wrote:
> As for per-doc auth: It is very hard to get right and probably
> against the nature of CouchDB. I'm not saying we shouldn't try
> to solve it, but we need to be aware of the impact.
> I remember Damien saying that Notes did get per-doc auth, but
> it wasn't a good solution and it sucked ever since. I don't
> think anybody here wants that :)

I'm currently looking for a clear explanation of what Notes did online
but I just hit lots of manuals with very little help. If someone has a
pointer here, I'd love to look into this.

> The biggest problem here are views, the reduced kind.

I kind of feel like views output something different enough from the
original document
that you should be able to tag each "document" that the view outputs
in a similar manner. It'd also be interesting to consider view
specific security defaults in a similar way to database security.

That still means that maps with a reduce on it would not compute based
on roles... but that the output would have to aggregate things in a
way which would produce the desired result. This basically means, it'd
be up to the view writer... not keeping them separate. In most of
those cases, I see separate databases as a better solution than clever
view partitioning per user.

Other questions:

Can the document security attributes add or only subtract from the
database security defaults?

Will we need a special category at the database level to note the
types of users allowed to apply custom document access control or is
the writer's group enough?

Do we need both read and write or just read since we have other
validation tools in place? Are there performance/efficiency concerns

Should we expand HEAD responses to include more information relating
to security?

> While that is conceptually rather easy, you are basically creating
> a view for each user. This may work for small amounts of data,
> but not large, and many users.

Exactly. I think multiple databases serves the purpose best here. If
you need to box data up you can replicate to by-user-filtered
databases or just keep separate databases to begin with.

In the end I think there are some elegant API's already in place that
seem like they'd be easy to transport as long as you don't make weak
assumptions of how security will apply (i.e. view results).

Right now I think a good route might be to experiment with
transplanting the db/_security API as a special document attribute. It
has simple semantics and could share the session system that the
database code paths use. It also avoids requiring JS to run any code
on requests.

There might be problems but I can't say we're better off not trying
something like this. Do others have ideas of how to take this work on?
Maybe a prototype could be built using a node.js proxy first.


View raw message