I would rather not put the decryption/encryption in the replicator because I like having the local database contents encrypted. Further, not all documents are encrypted, so it would have to do it selectively.
I have the source so I will check out those hooks in CBLModel where the properties are accessed and in justSave:'s propertiesToSave call. I'm not real happy about hacking it, though since any updates to CBL would have to have the same changes reapplied. I will follow up in another post with a few questions. Thanks. BTW, I don't understand your comment about it not being safe. I am loading the document, modifying it with putProperties:error: and (after that) creating the model from it. Instantiating the model does not modify the document. It is already modified by the time I instantiate the model. Unless, of course, putProperties:error: is asynchronous. On Thursday, February 13, 2014 10:24:45 AM UTC-8, Jens Alfke wrote: > > > On Feb 13, 2014, at 9:59 AM, Alan McKean <[email protected] <javascript:>> > wrote: > > On another note, I would like an opinion on the decryption/encryption that > I am using. I have a subclass of CBLMode called OTSCBLModel. It overrides > modelForDocument:encrypted: like this: > > > (Nit: Technically that's not an override, it's a separate method with a > different name.) > > + (CBLModel *) modelForDocument:(CBLDocument *)document > encrypted:(BOOL)encrypted > { > > ... > > [document putProperties:dictionary error:&error]; > > > This isn't a safe thing to do. Instantiating a model for a document should > not modify the document or have other side-effects. > > What I want is to leave the original in the db encrypted and the in-memory > properties unencrypted. > > > I don't think you'll be able to manage this without modifying CBLModel. If > you look through its source code you'll see there are three places where > `document.properties` is referenced. Those are places where the decryption > would need to be inserted. > > In addition, there is one call to -propertiesToSave in the -justSave: > method. Right after this is where the encryption would need to happen. > > Keep in mind that while this will let you access the actual properties via > the CBLModel API, it won't make them available to map functions, so you > still won't be able to do any queries against the encrypted properties. > > Is there a way to 'putProperties' in the document that does not update the > document on disk? > > > No. -putProperties is explicitly to save properties back to the database > on disk. (And even if you could have this in-memory modification, it still > wouldn't be visible to the map function so it still wouldn't work with > queries.) > > I think the real solution is going to be to hack some hooks into the > replicator so that it can decrypt docs before adding them to the local db > and encrypt them before uploading them. I don't have the bandwidth to do > this right now, but I can offer advice if you want to do it. > > —Jens > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/4bbe2a88-8e00-4ce6-8a47-2b8d22e2086a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
