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.
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.
throw({forbidden: 'Only administrators can write changes'});
IIRC, it raises either a 401 or 403 HTTP error.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.