The alternative (other than hacking the source for CBLModel) might be to create an alternate, decrypted representation of the CBLModel, e.g., OTSModel and use that in the app for display. Then when it comes time to save, get the original document and putProperties: (after encryption) back into the original. So far, I don't need to query the documents other than getting them by 'type' which is in the unencrypted part of the document.
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/2d8a9e71-d5be-453f-aadb-3f356b11b813%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
