Setting the channels on an iOS CBLModel object

[Brendan Duddridge]

Hi,

There seems to be a channels property on CBLReplication used for filtering, but not on CBLDocument or CBLModel.

Is "channels" a keyword then for an NSArray property that I would add to my CBLModel subclass in order to facilitate assigning documents to channels?

Thanks,

Brendan

[Jens Alfke]

On Nov 5, 2015, at 11:42 AM, Brendan Duddridge <bren...@gmail.com> wrote:

There seems to be a channels property on CBLReplication used for filtering, but not on CBLDocument or CBLModel.

Channels are really only a server-side concept. The replicator sends that channel list to the server via the _changes feed, and the filtering is done on the server. The channel assignments of documents are not downloaded by the replicator, so there’s nothing for local code to filter on.

Is "channels" a keyword then for an NSArray property that I would add to my CBLModel subclass in order to facilitate assigning documents to channels?

Document/channel assignments are done by the JavaScript “sync function” in Sync Gateway. The channels are used for access control and routing to clients.

—Jens

[Brendan Duddridge]

Oh I see. Sorry. My misunderstanding.

I need to be able to create a channel for every database document, so I was thinking that would be done on the client side. It's the client who creates the database on their local device (with a unique identifier - e.g. db-12abc987def2340cdg) and then I was thinking that channels would be the way to separate the data for one database from another. A user can have as many databases as they like on their devices and they would sync only the documents from the channels they have access to.

Rather than all their data in a single database, they can spread it out across multiple client side databases. I'm just trying to figure out how to setup sync for that architecture with Sync Gateway and Couchbase Server. 

Thanks,

Brendan

[Brendan Duddridge]

I was confused because the channels documentation mentions setting the channels property on the document itself. I didn't know this had to be done on the gateway.

However, one thing the documentation says is this:

Creating a sync function is a more flexible way to map documents to channels. A sync function is a JavaScript function that takes a document body as input and, based on the document content, decides what channels to assign the document to. The sync function cannot reference any external state and must return the same results every time it's called on the same input.

So that leads me to believe that maybe I do need to set a property on my model object that can then be used to assign the document to the channel on the Sync Gateway. Maybe instead of calling it channel on the model, I call it "database_id" or something like that. Then the database_id is used as the channel name on the Sync Gateway.

Perhaps the "database_id" along with a username property? I still need to figure out how authorization and managing user accounts works.

Would something like that work?

Thanks,

Brendan

[Jens Alfke]

On Nov 5, 2015, at 9:01 PM, Brendan Duddridge <bren...@gmail.com> wrote:

I was confused because the channels documentation mentions setting the channels property on the document itself. I didn't know this had to be done on the gateway.

Thats referring to the default sync function that you get if you don’t specify any in the SG config. It operates by just looking at a “channels” property in the document and assigning the doc to those channels. This function literally just consists of

function(doc) { channel(doc.channels); }

So yeah, one very simple way of assigning channels is by having a property in the document that explicitly lists the channels to assign the document to.

So that leads me to believe that maybe I do need to set a property on my model object that can then be used to assign the document to the channel on the Sync Gateway.

In a sense, the document has to contain the information on what channels to assign it to, because the sync function isn’t allowed to consult any external state, just the document.

—Jens

[Brendan Duddridge]

Thanks Jens. That's good to know.

But doesn't that also mean that a user could theoretically alter the document (say, outside the app with a database editing app such as SQLIteManager) and affect where that document gets synced to?

For example, say a username field is used to assign documents to channels and a user edits the document JSON directly to change the username to "fred" even though he's "steve" and then that document gets assigned to the "fred" channel. Fred then downloads that document to their device because Steve buggered up the document's username property?

Or is there protection in place to prevent a user from syncing documents that are outside of the list of channels they are assigned to?

Thanks,

Brendan

[Jens Alfke]

On Nov 6, 2015, at 1:50 AM, Brendan Duddridge <bren...@gmail.com> wrote:

For example, say a username field is used to assign documents to channels and a user edits the document JSON directly to change the username to "fred" even though he's "steve" and then that document gets assigned to the "fred" channel. Fred then downloads that document to their device because Steve buggered up the document's username property?

That’s why the sync function has to do validation of incoming documents.

(I hate to say “RTFM”, but this is covered in the docs about the sync function.)

—Jens

[Brendan Duddridge]

Sorry, there's a lot to get your head around with Couchbase and Sync Gateway and channels and authorization, etc. I didn't see this particular question addressed in the online manual so I asked it here. I was just trying to find out what would happen if a user tried to do this sort of thing.

[Jens Alfke]

On Nov 6, 2015, at 1:29 PM, Brendan Duddridge <bren...@gmail.com> wrote:

Sorry, there's a lot to get your head around with Couchbase and Sync Gateway and channels and authorization, etc. I didn't see this particular question addressed in the online manual so I asked it here. I was just trying to find out what would happen if a user tried to do this sort of thing.

http://developer.couchbase.com/documentation/mobile/1.1.0/develop/guides/sync-gateway/sync-function-api-guide/validation/index.html

It’s critical that the sync function treat all incoming documents as untrusted, and validate the sh*t out of them. Even if you’re sure your app would never create invalid documents, that doesn’t stop an attacker from sending bogus docs directly to the SG REST API.

—Jens