> The answer I got to this problem was "design middleware that handles this for you" which has to be a joke

It's not a joke.

The couch security model doesn't match the requirements of multi-user untrusted clients typical of internet distributed applications. But then most database have a similar limitation, it's only more visible in CouchDB because you can read/write documents directly from a browser without an application server, so the next logical step is to just let clients read/write directly to CouchDB over the internet without an app server.

If your data is in postgres, you will need an application server handing access control, business logic, and serialization.

If your data is in CouchDB, you need a proxy server that handles access control, whitelisting certain URL patterns and body content based on user entitlements.

Can you not write validation functions in design documents that handle the security (to a degree) for you? I seem to remember being able to do this in CouchDB 1.6 and, while it seemed like a pretty crude method, it was easier than managing an interposing proxy server.

Can you fake a reasonably indistinguishable 404 response for content that exists, but should not be publicly discoverable?

In the validation function docs [1], there is an example of HTTP errors being thrown, I'm just not sure if there is something like a `throw({notFound: null})` option.

[1] http://guide.couchdb.org/draft/validation.html

The only validation function I've written contains this:

    throw({forbidden: 'Only administrators can write changes'});

IIRC, it raises either a 401 or 403 HTTP error.

That's not too difficult to do with a server side script that accesses the database as an Admin user.

I use perl cgi scripts to handle that. There are perl modules for interfacing with CouchDB but you can also create a simple "curl" call to do it.

I have run into some issues with encoding/decoding JSON doing that with perl though, but I've not looked far into how they might be solved yet.