4

Problem

I have a database of recordings recordingsDB sent from a client application which uses pouchDB. Each recording is it's own document. e.g.

{
  "_id": "2019-10-20T04:51:22.744Z",
  "_rev": "1-53e73be51ea76f96e3cfde2de1502439",
  "locale": "en",
  "_attachments": {
    "recordings.webm": {
      "content_type": "audio/webm; codecs=opus",
    ...
    }
  }
}

The client application has a single user clientUser (so anyone accessing the website becomes clientUser). The client user can therefor write to recordingsDB but also read from recordingsDB which is not desirable because they can read any recordings from recordingsDB.

I went down "write only" database road and came across this answer from 2011. I'm wondering how to implement that.

Idea

So what I believe would work is if my recordingsDB would replicate all of the recordings to a masterRecordingsDB where the clientUser is no longer a member. After each document from the recordingsDB is copied to the masterRecordingsDB it would be deleted.

Setup

I have configured a replicator which copies the content from recordingsDB to masterRecordingsDB.

{
  "_id": "recordings_to_master_recordings",
  "_rev": "3-a6fa84dd89c2ec037353c17f65b4c765",
  "continuous": true,
  "source": {
    "url": "http://localhost:5984/recordings",
    "headers": {
      "Authorization": "Basic YWRtaW46cGFzc3dvcmQ="
    }
  },
  "target": {
    "url": "http://localhost:5984/master_recordings",
    "headers": {
      "Authorization": "Basic YWRtaW46cGFzc3dvcmQ="
    }
  },
  "user_ctx": {
    "name": "admin",
    "roles": [
      "_admin"
    ]
  },
  "owner": "admin"
}

How can I delete the items in recordingsDB after each successful replication?

Eric
  • 795
  • 5
  • 21
  • Seems like you should already have the pieces to solve this more easily. Usually, the app server sitting between the the Internet and db enforces authn and auhtz. In your example, the app server should stop requests for data belonging to someone else, returning 403 Forbidden or something. The app user is _not_ the same as the db user. i.e. you are `Eric-PNGK` here, but the db account used by the stackoverflow app server to store this question is _not_ `Eric-PNGK`; it's a system-level Microsoft Sql Server account that is zealously guarded by the app server. – deridex Oct 22 '19 at 16:05
  • With CouchDB / PouchDB. Each user has their own database. I have to avoid this and have all clients on a single database. Therefor all clients are the same app user. To help insure the anonymity of the end users this feature was requested. So i do believe in this case all client users are also the same database user. – Eric Oct 23 '19 at 06:45
  • You can tell pouch db to replicate the changes to the master db and not the other way around. I mean you can do something like: localDB.replicate.to(remoteDB) and so only the local changes will reach the couchDB and if something is changed/added on couchDB by another user then this will never reach the local pouch db. – needsleep Oct 24 '19 at 13:34
  • @needsleep That is true, and what we are currently doing. The issue is if someone was to find the uname and password of this client user. They could then for instance use curl to access the recordingsDB and get the information for all users. – Eric Oct 25 '19 at 10:56

1 Answers1

0

There are two methods I can think of to approach your problem.

Normally, in CouchDB, document deletion is a bit of a misnomer. When a document is deleted, due to the append-only nature of CouchDB, a new revision of the given document is created, consisting solely of its ID, revision, and the field _deleted which is true. This 'tombstone' as it's called allows for the deletion to be replicated across all databases. However, the tombstone remains in the database and takes up (albeit very small) space. You could implement this yourself, and just create a revision of the document that looks something like {"_id": "0", "_rev": "1-62657917", "_deleted": true}. It is important to note that documents with the deleted flag will not be returned in requests anymore.

The second option for deletion is purge. This will permanently remove all references to a given document from a database. This is not the standard form for deletion in couchDB, information on how to format a purge request is linked below.

More information:

CouchDB Docs on Deletion

CouchDB Docs on Purge

And finally, a helpful article about deletion in CouchDB

Carson
  • 2,700
  • 11
  • 24
  • Hi Carson, thanks for this but it doesn't answer my question. I'm aware of how to delete a document in CouchDB. The issue i'm running into is how to have a document automatically deleted immediately after replication takes place. – Eric Oct 23 '19 at 06:41