Re: NSPersistentDocument, Core Data & Cryptation
Re: NSPersistentDocument, Core Data & Cryptation
- Subject: Re: NSPersistentDocument, Core Data & Cryptation
- From: mmalcolm crawford <email@hidden>
- Date: Fri, 17 Jun 2005 11:58:57 -0700
On Jun 17, 2005, at 5:14 AM, Nicko van Someren wrote:
*** Uncaught exception: <NSInvalidArgumentException> CoreData
only supports file URLs.
While I can see why it would be necessary to impose such a
limitation on SQLite stores it seems a rather unnecessary
restriction on stores which load the whole file at once. Come on
Apple; we live in a web connected world so why can't we read our
data files over HTTP, FTP or something else we've not thought of yet?
This is a general issue with Cocoa. Please file an enhancement request.
Note, though, that in general there's probably little reason why data
could not be read -- the problem is more likely to be with *writing*...
As it stands I don't think that there is an easy way to handle your
encrypted data problem. Your best bet is probably going to be to
modify the dataRepresentationOfType implementation to write the
document to a temporary file, read it back in, encrypt it and then
spit it back out, possibly with the meta-data being added at this
level. Then you can make loadDataRepresentation do the reverse.
This has numerous drawbacks (the cleartext is written to disc, it
doubles the memory usage etc.) but it will probably work.
NSPersistentDocument does not use dataRepresentationOfType or
loadDataRepresentation; moreover these methods are deprecated.
There are several other approaches that you could *probably* (I
haven't tested these, but can't offhand think of a reason why they
should not work) take:
(a) Create custom classes for your entities and implement -willSave
and -didSave. In willSave, encrypt the attributes; in didSave,
restore them. You will also have to unencrypt values in
awakeFromFetch. The disadvantage here is that each value is
encrypted individually, so that an attacker has a lot more data to
work with.
(b) Create custom classes for your entities and make your attributes
transient. Add a 'data' attribute that serves as the backing store
for all your attributes. In willSave, collect all the attribute
values into a single value (likely NSData) and encrypt that. You
will again have to unencrypt and reconstitute values in
awakeFromFetch. This has the minor advantage that with all your data
grouped into a single value, it probably presents a harder target.
(c) Use an in-memory store and your own custom file format. In this
case it may be easier to use NSDocument instead of
NSPersistentDocument, and to create the persistence stack yourself.
When you read a file, you will have to unencrypt it, recreate the
managed objects, and insert them into the context etc. When you
save, you will have to retrieve all the managed objects from the
store, create and encrypt an archive of those objects, and write them
to a file (in this case you may be able to leverage dataOfType:error:
etc.)
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden