• Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.2
    • Fix Version/s: None
    • Component/s: HTTP Interface
    • Labels:
    • Skill Level:
      New Contributors Level (Easy)


      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.


      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.

      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



          • Assignee:
            Jason Smith
          • Votes:
            6 Vote for this issue
            9 Start watching this issue


            • Created: