On 28/05/2012, at 1:42 PM, Quincey Morris wrote: > On May 27, 2012, at 19:44 , Graham Cox wrote: > >> The only feature of my app that is really affected by this is the ability to >> directly browse a user's iPhoto Library. I use elements of Karelia's iMedia >> framework to enable this, but sandboxing thwarts it, for fairly obvious >> reasons (iMedia peeks directly at iPhoto's preferences and grabs resources >> from the common frameworks used by iWork for icons and so on, as well as >> going into the iPhoto library itself for images). >> >> Our users love this feature. Has Apple given us a way to do it officially so >> we can keep our users happy while also toeing the line on sandboxing? If so, >> some pointers to that would be welcome at this point. > > AFAIK, the (a?) correct procedure is to ask the user to locate the items you > want to reference, using the standard Open dialog. (This gives the user a > chance to opt out.) From the result, you'll need to create a > "sandbox-bridging" bookmark to the relevant "authenticated" URL, and store > the bookmark in your own sandbox. Then, in future invocations of your app, > you should be able to resolve the bookmark silently. > > The only fly in the ointment here is that the special bookmark requires a > recent version of OS X. (I can't remember which one, perhaps it was 10.7.3.) > On older versions, your only options would be to (a) withdraw the feature, or > (b) ask the user the first time the reference is needed in each app > invocation. (Well, the in the case of grabbing resources, you might be able > to keep the resources themselves in your sandbox, and not have to go back to > the source again.)
OK, I've found some discussions and info elsewhere along these lines which gives me something to work on. I'm not against asking the user for permission to do this, as long as it doesn't become too intrusive. Currently though, my implementation falls at the first hurdle, which is here: CFArrayRef recentLibraries = CFPreferencesCopyAppValue((CFStringRef)@"iPhotoRecentDatabases",(CFStringRef)@"com.apple.iApps"); This returns nil in the sandboxed version, even though I have added /Library/Preferences/com.apple.iApps.plist to my temporary exception entitlements (user relative, read only). Oddly, I do not get a sandboxd deny logged, which is why I was assuming it wasn't working at first. It must be something else, but it works just fine in the non-sandboxed app. Anyone else run into this? > >> If not, words fail me...... > > Well, I understand the frustration, but you *have* been getting somewhat of a > free ride. > > You have (in effect, like a lot of us) been poking around in the user's file > system and grabbing whatever you want. There's no *essential* difference > between that and malware. That last statement has very sharp corners and is > hard to swallow, but it seems inescapable if we are to have our security be > actually, you know, secure. Well, perhaps. But it's not really developers getting a free ride as much as users getting used to a nice feature that makes their apps easier to use. I'm far from the only app doing this, many do, and many integrate the entire iMedia browser to do it as well. I guess what pains me is that Apple have not as yet provided a sanctioned way to implement this feature. Maybe they will in future and I certainly hope so, but what's nasty about the current situation is that they have not made an officially sanctioned API available BEFORE imposing the sandboxing requirement on app developers. To me, that's pretty heavy-handed behaviour. I could understand it to a degree if there was a major issue right now with malware using this sort of thing to do its dirty work that needed to be shut down urgently, but AFAICS, it's a non-issue in practice. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
