[jira] [Commented] (COUCHDB-1287) Inbox Database (write-only mode)
[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107602#comment-13107602
]
kowsik commented on COUCHDB-1287:
-
Just a dumb question, that maybe outside the scope of this write-only mode. Is
there a way to use the update/validate handlers to rate-limit and or restrict
the writes in some ways? Given the writes are effectively coming from an
untrusted source, it won't take long to fill the disk *very* quickly.
Inbox Database (write-only mode)
--
Key: COUCHDB-1287
URL: https://issues.apache.org/jira/browse/COUCHDB-1287
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Affects Versions: 2.0
Reporter: Jason Smith
Priority: Minor
Currently, we can only grant combined read+write access in the _security
object members section. A user can either do both or neither. This prevents
a very common requirement for couch apps: sending private information from
less-privileged users to more-privileged users.
There is no (reasonable) way to make an inbox where anybody may create a
doc for me, but only I may read it. An inbox database allows user-to-user, or
user-to-admin private messages. (Not only chat messages, but asynchronous
notifications--with a per-user inbox, perhaps even service requests and
responses.)
There is no reason _security.members (formerly .readers) should control write
access. validate_doc_update() functions do this better.
I propose a boolean flag, _security.members.allow_anonymous_writes. If it is
true, then CouchDB will allow document updates from non-members, giving
validate_doc_update() the final word on accepting or rejecting the update.
Requirements:
1. Everything about _security stays the same (backward-compatible)
2. If members.allow_anonymous_writes === true, then most PUT and POSTs may
proceed
3. All updates are still subject to approval by all validate_doc_update
functions, same as before.
The following unit tests cover as much of the functionality as I can think
of. (My patch is unfinished but X indicates that I have it working.)
X Set a database with validate_doc_update, members != []
X member can write
X non-member cannot read
X non-member cannot write
X non-member cannot write even with .is_ok = true
X Set inbox mode
For non-member:
X cannot update with .is_ok = false (still subject to validator)
X can create with .is_ok = true
X can update with .is_ok = true
X Can store an attachment with _attachments
X Can store attachments via direct query
X Can delete an attachment via direct query
X can delete the doc
X can create via an _update function
X can update via an _update function
* None of these should work:
X POST a temp view
X POST a view with {keys:[keys, which, exist, and some which
don't]
* POST /db/exist X-HTTP-Method-Override: GET
* POST /db/_all_docs
* POST /db/_changes
* For _show and _list:
* POST
* OPTIONS
* VARIOUS, NONSTANDARD, METHODS (in case Couch allows them later)
* These syntax/semantic errors in _security should all fail:
* .members.required_to_write = null, [missing], , 0, true, 1, false,
[false], {false:false}
* .required_to_write = false
These are the known changes to the security model. I consider these all to be
either very unlikely in practice, or worth the trade-off.
* If you write to an inbox DB, you know, for a time, a subset of its
documents (but that's the point)
* An _update function could reveal a document to the user, with or without
changing it. However, an admin must install such a misguided update function.
* You can launch timing attacks to learn information about validate_doc_update
* You might discover whether doc IDs exist in the DB or not
* You might discover a well-known open source validation function. You can
look for bugs in its source code.
* Zero or more things which Jason can't think of
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COUCHDB-1093) Exceptions related to _changes + compact
Exceptions related to _changes + compact
Key: COUCHDB-1093
URL: https://issues.apache.org/jira/browse/COUCHDB-1093
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0.2
Environment: I don't believe this is OS and/or hardware elated, but
I'm running on a redhat 32-bit linux kernel
Reporter: kowsik
From the last thread on the dev mailing list:
On Fri, Mar 18, 2011 at 10:54 AM, Filipe David Manana fdman...@apache.org
wrote:
Ah,
I think the issue is while we are folding the by sequence btree, we
are not checking if the database file changed. So if compaction
finishes before finishing the btree fold, we reach that error.
I can't see right now any other situation, involving _changes, that
might cause that issue.
On Fri, Mar 18, 2011 at 5:40 PM, kowsik kow...@gmail.com wrote:
Been seeing this on our production CouchDB's (1.0.2) sporadically. We
are using the _changes feed, background view indexing and automatic
compaction.
Uncaught error in HTTP request: {exit,
{noproc,
{gen_server,call,
[0.1478.0,
{pread_iolist,290916},
infinity]}}}
Stacktrace: [{gen_server,call,3},
{couch_file,pread_iolist,2},
{couch_file,pread_binary,2},
{couch_file,pread_term,2},
{couch_db,make_doc,5},
{couch_db,open_doc_int,3},
{couch_db,open_doc,3},
{couch_changes,'-make_filter_fun/4-lc$^4/1-3-',2}]
Not reproducible yet, but it seems compacting while there are active
_changes listeners seems to trigger this. After the exception the
_changes listeners are disconnected which then connect back and
everything goes back to normal. beam itself holds up, though last
night it terminated with no logs, nothing. Just poof. Any ideas?
Thanks,
K.
---
http://blitz.io
http://twitter.com/pcapr
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-841) Support WebSockets in continuous changes feeds
[ https://issues.apache.org/jira/browse/COUCHDB-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006556#comment-13006556 ] kowsik commented on COUCHDB-841: feed=websocket so existing continuous feed types don't break? Support WebSockets in continuous changes feeds -- Key: COUCHDB-841 URL: https://issues.apache.org/jira/browse/COUCHDB-841 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 1.0 Reporter: Dirkjan Ochtman Just wanted to put this on the roadmap: it would be nice if continuous changes feeds (and maybe some other things in CouchDB, not sure) could support WebSockets. WebSockets are an emerging standard (there's no final spec yet) with implementations in both recent Chrome and Firefox (beta) releases that allows servers to push information to the browser without having to do polling (or longpolling). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1089) Let anonymous users access _active_tasks for view generation estimates
[ https://issues.apache.org/jira/browse/COUCHDB-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005988#comment-13005988 ] kowsik commented on COUCHDB-1089: - Bad idea. I've got a bunch of Couch's on EC2 and *do not* want anyone to access anything on these Couch's. I have the require_valid_user set to true with the assumption that everything's locked down. While EC2 security groups help, I'll sleep better knowing that Couch is not going to reveal anything to anyone without the required credentials. Let anonymous users access _active_tasks for view generation estimates -- Key: COUCHDB-1089 URL: https://issues.apache.org/jira/browse/COUCHDB-1089 Project: CouchDB Issue Type: Improvement Components: HTTP Interface, JavaScript View Server Reporter: max ogden Priority: Minor Labels: http, view Original Estimate: 3h Remaining Estimate: 3h Currently you have to be a database administrator to access _active_tasks. For UX purposes I would like to allow anyone to see view generation statuses, preferably on a per database level. This solves the problem of the first user to generate a view that then receives no time estimate as to when their process will be completed. I can't think of an application use case for making replication data public. I spoke with Volker Mische about the implementation details on this issue and he asserted after a code dive that it appears achievable, though the innards of the view status code were not familiar to him. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
