You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2014/01/01 21:47:10 UTC
Re: Disabling doc include
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
Re: Scaling db-per-user (Was: Re: Disabling doc include)
Posted by Jens Alfke <je...@couchbase.com>.
On Jan 2, 2014, at 12:17 PM, Jan Lehnardt <ja...@apache.org>> wrote:
We added /_db_updates in 1.4.0 that allows building the above with the difference that a replication only runs for active users, thus delaying most of the work until it is needed *and* avoiding having to run hundreds of thousands of replications at the same time.
I’ve looked up the API docs for _db_updates*, but I don’t see how it’s related to this topic. It appears to be a server-level changes feed that tells you when databases are created/deleted/changed.
I can see that you might use this to watch all the user databases and, when one changes, start a one-shot push replication to the central db. But the flip side is that when the central db changes you have to push the change to every single user database, and this doesn’t help with that.
—Jens
* http://docs.couchdb.org/en/latest/api/server/common.html#db-updates
Scaling db-per-user (Was: Re: Disabling doc include)
Posted by Jan Lehnardt <ja...@apache.org>.
On 02 Jan 2014, at 21:08 , Jens Alfke <je...@couchbase.com> wrote:
>
> On Jan 2, 2014, at 11:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Out of curiosity, what scaling limit have you found? Is this documented somewhere?
>
> By “we found” I should have said “we extrapolated”. We have customers that will need hundreds of thousands of user accounts, and attaching that many replications to a central master database wouldn’t be practical. Especially since they’d be filtered replications — every time a document was added to the master database, CouchDB would have to run n filter functions to decide whether to push it to n different user databases. Another scaling factor is that, if documents are accessible to many users, the storage space needed for those documents will be greatly multiplied since many replicas of them will exist.
>
> If someone only needs a few hundred user or user-subset databases, though, this should be a feasible approach.
Thanks Jens. Sounds sensible to me.
We added /_db_updates in 1.4.0 that allows building the above with the difference that a replication only runs for active users, thus delaying most of the work until it is needed *and* avoiding having to run hundreds of thousands of replications at the same time. Managing all that however is still an exercise left to the user (I know of two implementations of this in node) and we should see if we can smart up the replicator accordingly.
Storage aside, do you thing that would worked for your scenario?
Re: Disabling doc include
Posted by Jens Alfke <je...@couchbase.com>.
On Jan 2, 2014, at 11:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Out of curiosity, what scaling limit have you found? Is this documented somewhere?
By “we found” I should have said “we extrapolated”. We have customers that will need hundreds of thousands of user accounts, and attaching that many replications to a central master database wouldn’t be practical. Especially since they’d be filtered replications — every time a document was added to the master database, CouchDB would have to run n filter functions to decide whether to push it to n different user databases. Another scaling factor is that, if documents are accessible to many users, the storage space needed for those documents will be greatly multiplied since many replicas of them will exist.
If someone only needs a few hundred user or user-subset databases, though, this should be a feasible approach.
—Jens
Re: Disabling doc include
Posted by Jan Lehnardt <ja...@apache.org>.
On 02 Jan 2014, at 20:49 , Jens Alfke <je...@couchbase.com> wrote:
>
> On Jan 2, 2014, at 4:20 AM, Robert Newson <rn...@apache.org> wrote:
>
>> It is relevant, the OP could use multiple databases to expose the subset of documents to the appropriate subset of users.
>
> True. But FWIW, we found in 2012 that this setup is a hassle to configure (i.e. provisioning user accounts on demand) and won’t scale to large numbers of users (or subsets of users, if you partition that way.)
Out of curiosity, what scaling limit have you found? Is this documented somewhere?
Best
Jan
--
>
>> Mentioning Couchbase is not relevant. :)
>
> The Sync Gateway is replication-compatible with CouchDB. I think it’s as relevant to mention here as, say, PouchDB.
>
> —Jens
Re: Disabling doc include
Posted by Jens Alfke <je...@couchbase.com>.
On Jan 2, 2014, at 4:20 AM, Robert Newson <rn...@apache.org> wrote:
> It is relevant, the OP could use multiple databases to expose the subset of documents to the appropriate subset of users.
True. But FWIW, we found in 2012 that this setup is a hassle to configure (i.e. provisioning user accounts on demand) and won’t scale to large numbers of users (or subsets of users, if you partition that way.)
> Mentioning Couchbase is not relevant. :)
The Sync Gateway is replication-compatible with CouchDB. I think it’s as relevant to mention here as, say, PouchDB.
—Jens
Re: Disabling doc include
Posted by Robert Newson <rn...@apache.org>.
It is relevant, the OP could use multiple databases to expose the subset of documents to the appropriate subset of users.
Mentioning Couchbase is not relevant. :)
B.
On 2 Jan 2014, at 00:40, Jens Alfke <je...@couchbase.com> wrote:
>
> On Jan 1, 2014, at 3:27 PM, Robert Newson <rn...@apache.org> wrote:
>
>> There’s no document level read protection, but you can certainly grant or deny read access to users on a per database basis.
>
> Yes, but that isn’t relevant to what the OP is trying to do, i.e. give users access to some data but not all of it.
>
>> 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.
>
> Yes. I only brought it up because it’s the only way I know of to enable some form of per-document read protection using Apache CouchDB (as opposed to something similar-but-not-the-same, like Couchbase Sync Gateway.)
>
> —Jens
>
Re: Disabling doc include
Posted by Jens Alfke <je...@couchbase.com>.
On Jan 1, 2014, at 3:27 PM, Robert Newson <rn...@apache.org> wrote:
> There’s no document level read protection, but you can certainly grant or deny read access to users on a per database basis.
Yes, but that isn’t relevant to what the OP is trying to do, i.e. give users access to some data but not all of it.
> 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.
Yes. I only brought it up because it’s the only way I know of to enable some form of per-document read protection using Apache CouchDB (as opposed to something similar-but-not-the-same, like Couchbase Sync Gateway.)
—Jens
Re: Disabling doc include
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jan 2, 2014 at 12:27 AM, Robert Newson <rn...@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.
>
>
There is also the coming validate_doc_read [1] function from rcouch. Not
sure if it will be added in the final merge, but this something we could
investigate.
- benoit
[1] https://github.com/refuge/rcouch/wiki/Validate-documents-on-read
.
>
> On 1 Jan 2014, at 20:47, Jens Alfke <je...@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
> >
>
>
Re: Disabling doc include
Posted by "Florian Westreicher Bakk.techn." <st...@meredrica.org>.
List function are bad for performance since they are evaluated every time they run. I wanted to avoid them and use views (disk storage is cheap, CPU is not)
Stanley Iriele <si...@gmail.com> wrote:
>Correct me if I'm wrong here... If every doc had some meta info with
>it...
>And every URL rewrite went to a show or list function...couldn't you
>use
>the sec object passed on the request object to get what you want?... Or
>pass in some application level user credentials... Granted that doesn't
>sound very elegant
>On Jan 2, 2014 7:22 AM, "Robert Newson" <rn...@apache.org> wrote:
>
>>
>> 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. <
>> stuff@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 <rn...@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 <je...@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.
>>
>>
--
Sent from Kaiten Mail. Please excuse my brevity.
Re: Disabling doc include
Posted by Keno Kuhlmann <ke...@gmx.de>.
On 02/01/2014, at 14:35, Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <ke...@gmx.de> wrote:
>
>> Happy 2014 @ the list,
>>
>> there is no document level (or even worse attribute level) access control
>> mechanism implemented in couched at this time, please correct me if I am
>> wrong. Any type of document level access control introduces problems with
>> either information leaking aggregate/reduce functions or plain wrong query
>> results. It does not matter if implemented inside couchdb or elsewhere.
>
>
>
> not sure what you mean there.
When using aggregate functions, e.g. count, counting all documents results either in leaking information (in case documents are counted that you do not have read access to) or the result is wrong (count reveals 2 documents, but in the db are much more). From a users point of view, it does not matter wether this behavior is introduced by couchdb code or somewhere else. In a lot of cases this is even what the user expects. For the App-developer it might be handy to have some functionality inside couchdb to avoid an external access control layer. validate_read might just be such a handy function. Filtering out GET (read) request on the http layer based on some document attributes might be helpful in some other cases.
>
>
>> Anyhow, many applications require access control, maybe we should collect
>> some ideas, best practices or implement some helping functions, such as
>> validate_read, rewrite/vhost layer, etc.
>>
> You mean like :
>
> https://github.com/refuge/rcouch/wiki/Validate-documents-on-read
>
> ?
>
>
yes
>
>
>> Keno
>>
>> On 02/01/2014, at 13:27, Stanley Iriele <si...@gmail.com> wrote:
>>
>>> Correct me if I'm wrong here... If every doc had some meta info with
>> it...
>>> And every URL rewrite went to a show or list function...couldn't you use
>>> the sec object passed on the request object to get what you want?... Or
>>> pass in some application level user credentials... Granted that doesn't
>>> sound very elegant
>>> On Jan 2, 2014 7:22 AM, "Robert Newson" <rn...@apache.org> wrote:
>>>
>>>>
>>>> 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. <
>>>> stuff@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 <rn...@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 <je...@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.
>>>>
>>>>
>>
>>
Re: Disabling doc include
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <ke...@gmx.de> wrote:
> Happy 2014 @ the list,
>
> there is no document level (or even worse attribute level) access control
> mechanism implemented in couched at this time, please correct me if I am
> wrong. Any type of document level access control introduces problems with
> either information leaking aggregate/reduce functions or plain wrong query
> results. It does not matter if implemented inside couchdb or elsewhere.
not sure what you mean there.
> Anyhow, many applications require access control, maybe we should collect
> some ideas, best practices or implement some helping functions, such as
> validate_read, rewrite/vhost layer, etc.
>
You mean like :
https://github.com/refuge/rcouch/wiki/Validate-documents-on-read
?
> Keno
>
> On 02/01/2014, at 13:27, Stanley Iriele <si...@gmail.com> wrote:
>
> > Correct me if I'm wrong here... If every doc had some meta info with
> it...
> > And every URL rewrite went to a show or list function...couldn't you use
> > the sec object passed on the request object to get what you want?... Or
> > pass in some application level user credentials... Granted that doesn't
> > sound very elegant
> > On Jan 2, 2014 7:22 AM, "Robert Newson" <rn...@apache.org> wrote:
> >
> >>
> >> 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. <
> >> stuff@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 <rn...@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 <je...@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.
> >>
> >>
>
>
Re: Disabling doc include
Posted by Keno Kuhlmann <ke...@gmx.de>.
Happy 2014 @ the list,
there is no document level (or even worse attribute level) access control mechanism implemented in couched at this time, please correct me if I am wrong. Any type of document level access control introduces problems with either information leaking aggregate/reduce functions or plain wrong query results. It does not matter if implemented inside couchdb or elsewhere. Anyhow, many applications require access control, maybe we should collect some ideas, best practices or implement some helping functions, such as validate_read, rewrite/vhost layer, etc.
Keno
On 02/01/2014, at 13:27, Stanley Iriele <si...@gmail.com> wrote:
> Correct me if I'm wrong here... If every doc had some meta info with it...
> And every URL rewrite went to a show or list function...couldn't you use
> the sec object passed on the request object to get what you want?... Or
> pass in some application level user credentials... Granted that doesn't
> sound very elegant
> On Jan 2, 2014 7:22 AM, "Robert Newson" <rn...@apache.org> wrote:
>
>>
>> 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. <
>> stuff@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 <rn...@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 <je...@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.
>>
>>
Re: Disabling doc include
Posted by Stanley Iriele <si...@gmail.com>.
Correct me if I'm wrong here... If every doc had some meta info with it...
And every URL rewrite went to a show or list function...couldn't you use
the sec object passed on the request object to get what you want?... Or
pass in some application level user credentials... Granted that doesn't
sound very elegant
On Jan 2, 2014 7:22 AM, "Robert Newson" <rn...@apache.org> wrote:
>
> 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. <
> stuff@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 <rn...@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 <je...@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.
>
>
Re: Disabling doc include
Posted by Robert Newson <rn...@apache.org>.
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 <rn...@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 <je...@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.
Re: Disabling doc include
Posted by "Florian Westreicher Bakk.techn." <st...@meredrica.org>.
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 <rn...@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 <je...@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.
Re: Disabling doc include
Posted by Robert Newson <rn...@apache.org>.
"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 <je...@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
>
Re: Disabling doc include
Posted by "Florian Westreicher Bakk.techn." <st...@meredrica.org>.
I was referring to Apache / nginx vhost. But I did not know this issue , good to know for the future.
Jan Lehnardt <ja...@apache.org> wrote:
>
>On 01 Jan 2014, at 23:32 , Stanley Iriele <si...@gmail.com> wrote:
>
>> Can't you just use vhosts and rewrites to take care of that?...
>Also...you
>> could use list functions to ad an extra step yo do anything you want
>with
>> the results of a view before sending it to a client
>
>vhosts are using the `Host` header in HTTP requests. While mandatory in
>HTTP 1.1, CouchDB will happily answer to HTTP 1.0 requests without a
>`Host`
>header and will serve the default `/` URL and any subsequent one.
>
>Do not use CouchDB vhosts as a security mechanism.
>
>Best
>Jan
--
Sent from Kaiten Mail. Please excuse my brevity.
Re: Disabling doc include
Posted by Stanley Iriele <si...@gmail.com>.
Well..thanks for that I didn't realize that. The solution I was suggesting
would have been places behind a reverse proxy of course
On Jan 2, 2014 1:12 PM, "Jan Lehnardt" <ja...@apache.org> wrote:
>
> On 01 Jan 2014, at 23:32 , Stanley Iriele <si...@gmail.com> wrote:
>
> > Can't you just use vhosts and rewrites to take care of that?...
> Also...you
> > could use list functions to ad an extra step yo do anything you want with
> > the results of a view before sending it to a client
>
> vhosts are using the `Host` header in HTTP requests. While mandatory in
> HTTP 1.1, CouchDB will happily answer to HTTP 1.0 requests without a `Host`
> header and will serve the default `/` URL and any subsequent one.
>
> Do not use CouchDB vhosts as a security mechanism.
>
> Best
> Jan
> --
>
>
>
>
> > On Jan 1, 2014 3:47 PM, "Jens Alfke" <je...@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
> >>
> >>
>
>
Re: Disabling doc include
Posted by Jan Lehnardt <ja...@apache.org>.
On 01 Jan 2014, at 23:32 , Stanley Iriele <si...@gmail.com> wrote:
> Can't you just use vhosts and rewrites to take care of that?... Also...you
> could use list functions to ad an extra step yo do anything you want with
> the results of a view before sending it to a client
vhosts are using the `Host` header in HTTP requests. While mandatory in
HTTP 1.1, CouchDB will happily answer to HTTP 1.0 requests without a `Host`
header and will serve the default `/` URL and any subsequent one.
Do not use CouchDB vhosts as a security mechanism.
Best
Jan
--
> On Jan 1, 2014 3:47 PM, "Jens Alfke" <je...@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
>>
>>
Re: Disabling doc include
Posted by Stanley Iriele <si...@gmail.com>.
Can't you just use vhosts and rewrites to take care of that?... Also...you
could use list functions to ad an extra step yo do anything you want with
the results of a view before sending it to a client
On Jan 1, 2014 3:47 PM, "Jens Alfke" <je...@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
>
>