I'm trying to delete files inside application folder from my Cocoa application. By enabling Sandbox mode, I'm not able to delete files inside application folder.
This Sandbox mode has some option for enabling Read/Write access to downloads, pictures, movies, music and user selected file.
Before that I enabled Read and Write Access for user selected file and done my deletion using NSOpenPanel. It works fine and deletes files inside application folder but it opens panel every time when I run my app. Here I dont want any user interaction/permission to delete files inside application folder. Is there any solution to delete files with above defined constraints.
You need to use Security-Scoped Bookmarks:
Your app’s access to file-system locations outside of its container—as granted to your app by way of user intent, such as through Powerbox—does not automatically persist across app launches or system restarts. When your app reopens, you have to start over. (The one exception to this is for files open at the time that your app terminates, which remain in your sandbox thanks to the OS X Resume feature).
Related
In our Mac App we have following credential to entitlement.plist which enables us to read/write to user's file system followed by file browser dialogue:
com.apple.security.files.user-selected.read-write
That does mean we able to read/write a file/folder if once accessed by file browser dialogue. We never able to read/write to files/folder if not accessed by file browser dialogue at least once in an application life cycle.
I didn't found any other possible credential too to entitlement.plist which can enable us read/write to files/folder by completely removing any use of file browser dialogue. Is there any way we can achieve this?
I assume your app is Sandboxed and if so, it's only possible to access the filesystem as defined here:
Powerbox and File System Access Outside of Your Container Your
sandboxed app can access file system locations outside of its
container in the following three ways:
At the specific direction of the user
By using entitlements for
specific file-system locations (described in Entitlements and System
Resource Access)
When the file system location is in certain
directories that are world readable
The OS X security technology that interacts with the user to expand your sandbox is called Powerbox. Powerbox has no API. Your app uses Powerbox transparently when you use the NSOpenPanel and NSSavePanel classes.
Well, the whole point of Sandboxing is to actually don't allow you to access user's files without their knowledge.
The only thing you can probably do is to use com.apple.security.temporary-exception.files.absolute-path.* entitlements to access some specific (read hard-coded) file system locations. You can learn more about temporary exceptions here: App Sandbox Temporary Exception Entitlements.
But keep in mind that you'll have to explain to the Apple Review Team why you need those exceptions in the first place.
My application downloads a PDF and stores it in the LocalState folder for my Windows 8 app.
I have a link within the app that I would like to show the PDF when the user clicks it.
I've tried displaying it using ms-appdata:///local/pdfs/filename.pdf in a window.open call and I also tried using the InAppBrowser plugin within cordova with no luck. Additionally, I've tried the following:
var uri = new Windows.Foundation.Uri('ms-appdata:///local/pdfs/filename.pdf');
var file = Windows.Storage.StorageFile.getFileFromApplicationUriAsync(uri);
Windows.System.Launcher.launchFileAsync(file).done();
I know the file exists as I'm getting a file result back. Just not sure how to allow the user to view it.
By design, the local appdata folder on Windows is accessible only to that app, or to full-trust desktop applications (and this is probably true of similar sandboxed locations on other platforms). As a result, a Windows Store app that gets launched with Launcher.launchFileAsync won't be able access that location (nor can a webview process, which is also sandboxed). If a desktop application gets launched, on the other hand, it probably can access the file, but you can't tell ahead of time if that's the case. Bottom line is that local appdata isn't a good location for letting other apps get at the file.
You'll need to save the file in another location that is accessible to other apps. There are two approaches here, both of which will require a little user interaction to select a location, so they can place the PDFs anywhere they want:
Have the user select a save folder for your app, which they can do once. You would invoke the FolderPicker for this purpose, and save the selected folder in the FutureAccessList. This way you can have the user select the save folder, which grants you consent to save there, and by saving it in the FutureAccessList you can retrieve it in subsequent sessions without having to ask the user again. Refer to the File Picker Sample and the File Access Sample for more.
Have the user select a save location for each individual file, using the FilePicker (see the same sample), and you can also use the access cache to save permissions to those individual locations if you need them later.
There might be Cordova plugins that work with these APIs too, but I haven't checked. Either way, once the file is in an accessible location, launching the file should work just fine.
As an alternate solution, you could consider rendering the PDFs directly in your app. Windows has an API for this in Windows.Data.Pdf, with an associated sample. There might be a plugin or other JS libraries that could also work for this.
When we try to delete/uninstall Cocoa .app file ,we directly move the .app file to trash.
This does not ensure the deletion of app user data folder in application support.
The user data lies there hanging. So i wanted to save the user data/ files inside application itself (app->showPacakge contents->somewhere).
If it is not possible! Any ways of clearing app user data folder in application support when user moves app to trash ?
Not a great idea.
The package content is signed. Any modification will be detected by the OS and will prevent launching of the app.
Not to mention the fact that you might not have access to the Applications folder, where most users will keep their app.
if you are using packages for installing your application, then you can have pre-install script, which deletes user data in the application support folder.
I'm currently adding Sandboxing support to my app.
Having give permission to my app to access a folder (by dragging it onto my Window) and I would now like to revoke that permission so that I can retest what happens before that permission is given.
How can I do that?
I'm not yet using URL bookmarks, and yet the permission persists across restarts of the application. I don't know if this is because it's a folder rather than a file?
Before you change the permissions of file or folder, you must store the current one for later use. I have never seen a method or system-call to restore previous permissions after a change.
I have a mac AVRecording app, which records a video and save it to a location selected via NSSavePanel. It was working fine till I sandboxed the app.
For sandboxing I have added the following entitlements
com.apple.security.files.user-selected.read-write
com.apple.security.assets.movies.read-write
com.apple.security.files.downloads.read-write
This enables saving to Downloads and movies folder only.
How is it possible to save my file to any desired location, Desktop, Documents etc ?
It's not clear from your question whether you are referring to saving a particular file (in which case you can use the NSSavePanel and manually copy the file using NSFileManager to write the file into the user-specified new file), or whether you are referring to having the user choose a location for all future downloads.
If you want to prompt the user for a location to use for future downloads, you'll need to use the secure bookmark entitlement and secure bookmarks to retain access to the folder.
There's another stackoverflow answer about sandboxing which covers the process of saving and using the secure bookmark.