It doesn’t achieve the same effect, though, the virtual host + url rewriter is not an access control mechanism. You’re still granting database-wide read permissions to the user.
B. On 2 Jan 2014, at 09:09, Florian Westreicher Bakk.techn. <st...@meredrica.org> wrote: > I put a design doc behind a desk record / virtual host, that should do the > trick. The user that is used by the app is read only > > Robert Newson <rnew...@apache.org> wrote: >> "there’s no notion of read-protection in CouchDB." >> >> There’s no document level read protection, but you can certainly grant >> or deny read access to users on a per database basis. That’s by design >> due to the ease that information could leak out through views >> (particularly reduce views). The restrictive proxy approach is brittle, >> it requires that you know all the URL patterns to block and keep them >> up to date when you upgrade CouchDB. It can work, it’s just not >> awesome. >> >> B. >> >> . >> >> On 1 Jan 2014, at 20:47, Jens Alfke <j...@couchbase.com> wrote: >> >>> >>> On Dec 31, 2013, at 1:44 AM, meredrica <st...@meredrica.org> wrote: >>> >>>> I expose CouchDB directly to mobile clients and wanted to hide some >>>> information from them. >>> >>> You can’t really do that; there’s no notion of read-protection in >> CouchDB. >>> As a workaround you can put CouchDB behind a proxy or gateway, and >> restrict the URL patterns that clients are allowed to send. >>> >>> —Jens >>> > > -- > Sent from Kaiten Mail. Please excuse my brevity.
