Perpetual permission dialogs in Mojave for a script app

[harald]

I have a script app that communicates with Finder, System Events and Acrobat Pro.
Since Mojave, the OS insists on asking for permissions to “control” these 3 apps.
I.e the usual message “This script needs to control other applications to run.”
The problem is that the system never learns the approvals! I get the same dialogs on the next run.

Details
The script app can either be dropped a PDF file (which invokes its Open handler), or one can select a PDF file in Finder and then double-click the app (or start it via FastScripts) which invokes the Run handler, which in turn gets an alias to the selected file, after which it invokes the Open handler for that PDF file).

If it is dropped a file, it will only ask for these permissions the first time, and once approved, it will not protest on the next run, so the system “learns”.

But if the app is invoked via FastScripts, or double-clicked, thereby invoking the Run handler, it never “learns”. Sometimes it works, but mostly not without these dialogs. If, on every run, I change to a new selected pdf file, it seems to always (or almost always) ask for permissions.

The script does have properties, but they never change, and the date of the app never change upon successive runs.

The Run handler asks Finder to get the selection. If no PDF file is selected, it will invoke a “choose file” dialog (i.e belonging to Standard Additions). The “choose dialog” command is outside of the Finder block.

Obviously, System Integrity does not like the Run handler!

In System Preferences, the script app is listed under Security/Privacy/Automation, and I have even given it Full Disk Access,

What shall I do to prevent these extremely obnoxious dialogs?
(I have already read https://latenightsw.com/mojave-documentation/)

I really really regret that I “upgraded” to that obnoxious Mojave last year! It came with nothing but problems! El Capitan was nicer!

[ShaneStanley]

Your problem is that AppleScript applets are potentially self-modifying: when a run handler has been completed, if any of the script’s top-level values have changed, the applet will attempt to save the updated script to disk. And every time an app is modified it needs re-authorizing (unless code-signed).

The simplest solution is to move your top-level code into a handler, like this:

on run
  my doStuff()
end run

on doStuff()
 -- your code in here
end doStuff

The script does have properties, but they never change

it’s not just properties — it’s all top-level variables, basically.

the date of the app never change upon successive runs

If you check, you will find that the modification date of the main.scpt file within it does.

[harald]

The simplest solution is to move your top-level code into a handler, like this:

on run
  my doStuff()
end run

on doStuff()
 -- your code in here
end doStuff

Magnificent Shane!
The reliever of terrible headaches!

But why did you put “my” there?
It works without “my”.
Does it have any beneficial effects to explicitly target the script with a my despite it is not really necessary?

the date of the app never change upon successive runs

If you check, you will find that the modification date of the main.scpt file within it does.

Ahh, insidious!
Never occurred to me to dive that deep.

BUT: The date of main.scpt changes anyway, even with your solution! Despite that, it does not trigger re-authorizing! How come?

[ShaneStanley]

But why did you put “ my ” there?

Habit. It doesn’t hurt.

The date of main.scpt changes anyway , even with your solution! Despite that, it does not trigger re-authorizing! How come?

I’m a bit surprised, but I suspect the check for changes is considerably more sophisticated than a simple check of modification date.

[redsweater]

This is a really interesting, nuanced behavior of AppleScript. Thanks, @ShaneStanley for getting to the bottom of it so quickly, and explaining it. I’ll be on the lookout for this kind of thing in the future. For scripts, I think I actually run them in a way that prevents self-modification, but of course for an applet all bets are off, since I just launch it like any other app.

[ShaneStanley]

For scripts, it shouldn’t matter for FastScripts because it’s the app itself that gets the permission, and the scripts are outside its bundle.

There are a couple of other wrinkles. If the script is on read-only media or has its permissions set to read-only, saving silently fails. So code-signing prevents changes by also making the main.scpt file read-only.

And if there’s an ASObjC value at the top-level, the script can’t be saved. This isn’t a silent error, although most apps, like FastScripts, trap it silently.

Lastly, since Mojave (and perhaps earlier) the OS is somehow stopping it from happening in scripts that have been granted Accessibility permissions. Previously, repeated requests for authorization were the norm there, too, but not any more.

It’s a bit odd that it’s been handled in just one area, but it doesn’t pay to spend too much time thinking about what’s odd these days. It would be nice if everyone filed requests for the ability to turn persistence off for applets.

Lastly, a couple of plugs. For those turning persistence off, don’t forget to turn off Persistent Properties in the Script menu of Script Debugger for such scripts. This makes Script Debugger also turn them off in your script, which means you reduce the chance of script behaving one way in an editor and another in-situ.

And with them off, you lose the ability to use properties for persistence of preferences. For an alternative way of storing preferences, see my PrefsStorageLib, which piggy-backs on user defaults:

https://www.macosxautomation.com/applescript/apps/Script_Libs.html