On Jan 2, 2014, at 12:17 PM, Jan Lehnardt
mailto:j...@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
On 02 Jan 2014, at 21:08 , Jens Alfke wrote:
>
> On Jan 2, 2014, at 11:56 AM, Jan Lehnardt 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 o
On Jan 2, 2014, at 11:56 AM, Jan Lehnardt 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
replica
On 02 Jan 2014, at 20:49 , Jens Alfke wrote:
>
> On Jan 2, 2014, at 4:20 AM, Robert Newson 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 hassl
On Jan 2, 2014, at 4:20 AM, Robert Newson 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)
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 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 o
I was referring to Apache / nginx vhost. But I did not know this issue , good
to know for the future.
Jan Lehnardt wrote:
>
>On 01 Jan 2014, at 23:32 , Stanley Iriele wrote:
>
>> Can't you just use vhosts and rewrites to take care of that?...
>Also...you
>> could use list functions to ad an ext
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" wrote:
>
> On 01 Jan 2014, at 23:32 , Stanley Iriele wrote:
>
> > Can't you just use vhosts and rewrites to take care of that?
On 01 Jan 2014, at 23:32 , Stanley Iriele 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 H
On 02/01/2014, at 14:35, Benoit Chesneau wrote:
> On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann 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
>> wro
On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann 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 prob
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 functio
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 v
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.
wrote:
> I put a design doc behind a desk record / v
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 wrote:
>
> On Jan 1, 2014, at 3:27 PM, Robert Newson wrote:
>
>> There’s no document le
On Thu, Jan 2, 2014 at 12:27 AM, Robert Newson 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 l
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 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
On Jan 1, 2014, at 3:27 PM, Robert Newson 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.
"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
restric
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" wrote:
>
> On Dec 31, 2013, at 1:44 AM, meredrica wrote:
>
On Dec 31, 2013, at 1:44 AM, meredrica 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 th
On 12/31/2013 10:23 AM, Alexander Shorin wrote:
There is no way to do such thing, but why do you need to do this?
--
,,,^..^,,,
I expose CouchDB directly to mobile clients and wanted to hide some
information from them. Setting up filtered replication seems like the
way to go for now but this i
There is no way to do such thing, but why do you need to do this?
--
,,,^..^,,,
On Tue, Dec 31, 2013 at 1:19 PM, meredrica wrote:
> Hello!
>
> Is there a way to disable ?include_docs=true for a view? Or is filtered
> replication the way to go for this?
>
> Happy New Year!
> Florian
Hello!
Is there a way to disable ?include_docs=true for a view? Or is filtered
replication the way to go for this?
Happy New Year!
Florian
24 matches
Mail list logo
