[
https://issues.apache.org/jira/browse/COUCHDB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829510#action_12829510
]
Juhani Ränkimies commented on COUCHDB-86:
-
Once I get my erlang build env set up, I
[
https://issues.apache.org/jira/browse/COUCHDB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829470#action_12829470
]
Mark Hammond commented on COUCHDB-86:
-
> If there are any Windows devs with Erlang expe
Hi James,
thanks for your thoughts. I do agree with most points. But I'd like to
propose a pragmatic way out.
I think Chris' auth design is pretty solid. We have been thinking about
this space for over two years now and this is first thing that makes me
happy.
Chris' auth design is also not "com
On Wed, Feb 3, 2010 at 1:35 PM, Brian Candler wrote:
> On Wed, Feb 03, 2010 at 09:24:26PM +, Brian Candler wrote:
>> > > (9) The _users db itself is world-readable (showing not only who your
>> > > users
>> > > are, but their password hashes). Highly undesirable.
>> >
>> > I actually consider
Hi Everyone-
I am just an end user of couch right now, but the development of these
security features are important to me so I thought I would share my
thoughts.
In general and specifically regarding points 5 and 9, I have to agree very
passionately with Brian. There is no way that I want my u
On 3 Feb 2010, at 13:24, Brian Candler wrote:
>> _readers / _admins / _security are stored as a raw object without
>> concurrency control, because keeping them as a document adds too much
>> performance overhead on each request. Concurrency control is a
>> tradeoff we make here.
>
> Sorry to be
One last thing on _reader behaviour.
If you try to access a database as a non-admin user, but don't have _reader
rights, I think you should get a 404 back which is indistinguisable from
"database does not exist". Otherwise, you have an obvious way to probe for
database names, and if databases are
On Wed, Feb 03, 2010 at 09:24:26PM +, Brian Candler wrote:
> > > (9) The _users db itself is world-readable (showing not only who your
> > > users
> > > are, but their password hashes). Highly undesirable.
> >
> > I actually consider this a feature. We'd like to get some stronger
> > password
On Wed, Feb 03, 2010 at 09:21:10AM -0800, Chris Anderson wrote:
> Let me see if I can address some of these concerns.
Thank you for taking the time to reply in detail and to implement some of
the changes.
> > I believe that in its current form, _all_dbs simply won't scale to millions
> > of datab
[
https://issues.apache.org/jira/browse/COUCHDB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson closed COUCHDB-595.
-
> Expect/Continue support broken for non-chunked transfer uploads
>
[
https://issues.apache.org/jira/browse/COUCHDB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson resolved COUCHDB-595.
---
Resolution: Fixed
Fix Version/s: 0.11
> Expect/Continue support broken for non-chunke
[
https://issues.apache.org/jira/browse/COUCHDB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829195#action_12829195
]
Benoit Chesneau commented on COUCHDB-595:
-
it's committed. You can close this issu
On 3 Feb 2010, at 09:21, Chris Anderson wrote:
>> I do see logic in keeping the admin/reader authorizations for a database
>> within the database itself. The problems are:
>>
>> (1) _all_dbs currently shows everything - even those databases you don't
>> have access to.
>>
>> I believe that in its
On Wed, Feb 3, 2010 at 6:23 AM, Brian Candler wrote:
> I see the readeracl branch was recently merged into trunk, and I've just
> been testing it again.
>
> My concern is that the design is flawed, and that if this goes into 0.11
> then we are stuck with it forever; so it's better to address these
[
https://issues.apache.org/jira/browse/COUCHDB-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau closed COUCHDB-637.
---
Resolution: Fixed
Fix Version/s: 0.12
0.11
commited.
> more info
[
https://issues.apache.org/jira/browse/COUCHDB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829123#action_12829123
]
Paul Joseph Davis commented on COUCHDB-86:
--
COUCHDB-67 is only an outline for a re
I see the readeracl branch was recently merged into trunk, and I've just
been testing it again.
My concern is that the design is flawed, and that if this goes into 0.11
then we are stuck with it forever; so it's better to address these sooner
rather than later.
I do see logic in keeping the admin
On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote:
> If couchdb tracked replication by a Merkle tree, it would obsolete the
> update_seq mechanism?
Only if you weren't doing filtered/selective replication. And probably only
if there was nothing else different between the two databases
[
https://issues.apache.org/jira/browse/COUCHDB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829006#action_12829006
]
Juhani Ränkimies commented on COUCHDB-86:
-
I think this should be reopended because
19 matches
Mail list logo
