NSWorkspace openURL: fails on file:// URL but not https:// URL

Question

janice OP

Created Oct ’18

Replies 19

Boosts 0

Views 7.5k

Participants 3

I have a shipping Sandbox'd App that saves a thumbnail of an image if the user add's it to the App. It

also saves the original URL to that image with the thumbnail for reference later on.

If the user then later wants to "look" at the original image, I do:

[[NSWorkspace sharedWorkspace] openURL:photoURL]

which has worked in the past. Now it only half works in that, if the original image

came from an eg: http(s):// URL, the openURL will launch Safari with that URL. But if

the original image came from a file:// URL, it no longer launches eg: Preview or

the default Application for that file type, and instead fails and pops up a message

on my App saying "The application "<MyApp>" does not have permission to open

<imagename>.png".

(I checked and "

URLForApplicationToOpenURL:" returns Preview for

the default Application for the file. I also checked and no "error" messages show up

in the Console)

I don't have, and don't want, access to the original file in my App. I just

want to launch whatever viewer Application the user has configured.

Did something change security wise to make this feature impossible now?

Boost

Answer 1

john daniel OP

Oct ’18

I have to apologize. I think when I first read your post, I interpreted it to mean that it worked half the time. I can confirm that access to a user's home directory is very restricted. Files in any other location should open normally. I was going to suggest "activateFileViewerSelectingURLs", but you've already found that.

I think the database of security scoped bookmarks isn't such bad idea. Don't you already have that, more or less? You have a database of URLs. Just save bookmark data instead. You'll need to convert to a URL in order to use it, but that is what the rest of your code is expecting anyway.

0

Answer 2

janice OP

Oct ’18

> I can confirm that access to a user's home directory is very restricted. Files in any other location should open normally.

Yes, pretty much everything is restricted which is pretty much the point of the sandbox. But again, it's not my App that wants/needs access. It's just *any* App. Whatever App the user has previously said they wanted to have access to that file, ie: the configured default Application for that file (type). I still think this is *meant* to work, it just doesn't.

> I think the database of security scoped bookmarks isn't such bad idea. Don't you already have that, more or less?

Nope. No need for any security scoped bookmarks. No need for access to any other files other than my App's (self contained) database file. No separate database of URL's. If access to another file is needed for some reason, the user has to select it anyway, so therefore an NSOpenPanel so therefore that file is added (temporarily) to my sandbox. But there is no good reason to save access to that same file for later. If the user ever happens to need it again, I just NSOpenPanel and ....

But yeah, I could (security scope) bookmark every file that my App ever comes in contact with. But yeah, not there yet.

0

Answer 3

john daniel OP

Oct ’18

Apps typically don’t ”come into contact” with lots of other files. Apple designed the App Store sandbox for apps to work on their own documents, when the user opens them. If they need temporary files or databases, they can keep those in the container.

If you need to save a pointer to a file, then save a security-scoped bookmark. Clearly you do have such a database. If you didn’t, you wouldn’t have encountered this issue and you wouldn’t have started this thread. If you “come into contact” with a file and want to maintain that contact, you are going to have to use a security scoped bookmark.

0

Answer 4

john daniel OP

Oct ’18

Try the workaround posted here: https://forums.developer.apple.com/thread/109855

0