couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Couch as an App Server
Date Fri, 24 Jul 2009 00:59:07 GMT
On Thu, Jul 23, 2009 at 5:45 PM, Will Hartung<> wrote:
> I've written and restarted this email at least 4 times now :-)
> Sometimes, some of the old content carries forward, but mostly not.
> I wanted to comment on some of the distinctions the I see between an
> App Server and a DB server. This was prompted by a chat in IRC.
> After much rumination, and typing, I think I've formalized it down to
> a single point.
> The key difference between an Application Server and a Database Server
> is that the App Server has control over the services that it
> publishes, whereas a DB server does not.
> Simply, App Servers create and publish application specific APIs,
> whereas DB Server publish DB Server APIs.
> This is modulo any administration APIs the App Server may publish that
> are "out of control" of the developer.
> If Couch were to become an App Server, then, naively, it would publish
> both DB server APIs as well as the Application APIs.
> In the Application Server space, I think a Couch developer would need
> to be able have full control over whether the DB APIs are published.
> When someone publishes both the DB API and the Application API, again,
> naively, it's like publishing a OOP Class with all of the internal
> variables public. There is the potential for a client of the server to
> "route around" the Application API and work with the internal data
> directly. Not necessary a bad thing, but most probably not a good
> thing.
> Simple example.
> Back in the day, there was a proliferation of "Client/Server" "fat
> apps" that would run on client machines and were connected directly to
> backend databases. At a minimum, those C/S applications had embedded
> SQL code within them.
> If someone were to create a Javascript, browser based "fat app", using
> standard XHR techniques, pretty much anyone would consider it "insane"
> to have embedded SQL within the Javascript, implying that the server
> is actually accepting raw SQL strings from the client and executing
> them. To quote Linus Van Pelt: "Tooo dangerous".
> This would be similar to what would happen if you put a couch DB
> "live" on the web.
> How to work around it?
> The simplest case is to limit access to the DB API through security,
> providing separate security setups for Applicaton  APIs, and DB APIs.
> But, IMHO, that's quite limiting. I think folks will want to be able
> to publish Couch databases directly on to the web for use by Ajax
> clients.
> At the same time, I don't think they will necessarily want enable the
> entire database to be available to client. You may want to publish you
> blog content in Couch, as well as comments, and perhaps "private
> messages" in the same DB. A single _all_docs and those messages are no
> longer particularly private.
> That implies there needs to be some finer granularity.
> Perhaps we could selectively enable views to be readable, and that
> works fine as long as _doc_ids aren't "fishable" so folks can get docs
> outside of views. But with the common meme about incremental ids, that
> casts a bit of a shadow on that.
> What I think really needs to happen, though, is being able to
> intercept the requests going in to and out of the Database.
> In the Java world, you would implement a Servlet Filter.
> With a filter, combined with user credentials, you could deny requests
> for specific id patterns (user_*, say). Or, on return, you could
> introspect JSON payloads heading back and strip out sensitive
> information (delete payload['password']).

About to hop on a plane. The short answer is we've considered filter
functions run at request time to grant access to individual documents
or view rows. The reason we haven't done it is performance. Shelling
out to JS would be slow, if it happened on every request. The fast
version of this is doc-level access control lists with a known format,
so they can be tested against in Erlang. This I'd like to see,
although it's not top of my list as a priority. Patches welcome.


> The concept is simple, but it's a very powerful enabler.
> Later, as common use cases come up, (granular ACLs, or whatever),
> those could be made more "first class" within the Couch API, but until
> then, this mechanism is, I think, a great placeholder.
> It could even be placed on views, etc.
> To me, it's the "simplest thing" that works that can make Couch an
> acceptable App Server while still providing "native" DB functionality.
> Curious about your thoughts.
> Regards,
> Will Hartung

Chris Anderson

View raw message