We have run into a showstopper for our current project, where we ar going to run multiple applescripts for InDesign Server on a Mac Pro the usual way via SOAP calls. Since the new Mac Pro does not allow any older MacOS than Catalina, everything has to work with Catalina.
The scripts themselves works fine when run from Script Debugger or Script Editor (with some manageable gliches) – but not when started from SOAP calls. Then scripts are not allowed to send Apple events to other applications, which is essential to our solutions – and I have found no way to allow them.
That was not a problem on our test server, a Mac Mini with MacOS 10.14 Mojave. Via SOAP I could just execute a script that called all the applications need to automate, being prepared to, once for all, click “OK” on the dialogs that ask for approval for InDesignServer.command to send Apple Events on the script server.
So when running scripts from SOAP, InDesignServer.command, owns the process. However InDesignServer.command is not shown under Automation in the integrity settings of System preferences.
With Catalina those dialogs doesn’t show up att all. The scripts is just denied permission to do it’s tasks
If I catch the error it says, as expected, Not authorized to send Apple events to Finder, Not authorized to send Apple events to LNSOSAX or whatever application I try with.
I does not help to reset the database with `tccutil reset AppleEvents’. The dialogs just won’t show up. And since InDesignServer.command is not shown in the Automation panel there are no checkboxes to fill.
So… does anyone have the magic key to this?
What form are the scripts saved in?
Ordinary scpt-files.
Do you suggest code signed scptd-files? I haven’t tried that…
No, no difference with scptd (code signed) or applecript textfiles (as Adobe recommends)
Codesigning doesn’t do anything for .scptd files. Have you read this part of the Catalina release notes:
“To enhance security, AppleEvents and AppleScripts that target an app on a remote system must authenticate as the same user on the remote system. An AppleEvent that targets an app running as a different user receives a procNotFound error. To allow remote AppleEvents to target apps in any user session, run the following command in Terminal on the server:
defaults write /Library/Preferences/com.apple.AEServer RestrictAccessToUserSession -bool false
Then disable and reenable Remote Apple Events in System Preferences > Sharing. (5353592)”
Yes I have. My colleges on the node side says all processen is own by the same, logged in user. Despite that, I have tried the command to disable RestrictAccessToUserSession - with no success.
What I haven’t tried is disabling SIP on the machine. I’m planning to go to the office this weekend to try that, but have little hope since some people who have tried it (in other contexts) says it will not affect the automation integrity stuff.
I created a simple start script for InDesign Server: tell application id "com.apple.finder" to count windows
Then I ran tccutil reset AppleEvents from Terminal and restarted InDesign Server.
As a start script the process is owned by InDesign Server, as it is when executed from SOAP. But the result is the same, with nothing showing up in the integrity panel.
I think I have a solution.
I changed the above startup script to make osascript running the AppleScript command, for example
do shell script "osascript -e 'tell application \"Finder\" to display notification \"some stuff\"'"
Works! When running my test script from soap, the error message for sending Apple Events is gone.
I have’t yet managed to do the same other integrity settings, like network volume access.
For example, this won’t work in my startup script:
do shell script "echo test > /Volumes/MyVolume/.test.txt"
Neither do this:
do shell script "osascript -e 'do shell script \"echo test > /Volumes/MyVolume/.test.txt\"'"
Then I just get a permission denied message, no question to give access.
I discovered this problem occurs only when InDesign Server (IDS) is started by a launch agent (or launch deamon).
When started from Terminal, there is no problem: the system ask for permissions for IDS to get network volume access, so that we can approve it.
Another error, probably very related, happens when trying to open files when IDS is started by a LaunchAgent: Opening an indesign documents located in Desktop or a network volume returns indesign error 29445 (file open in another application) – but when it’s located in /tmp there is no error. Also this doesn’t happen when IDS is started from the terminal in Catalina, and didn’t happen with Mojave at all.
But starting IDS with LaunchAgents is what we need to do to, for stability.
Adding launchd to Full Disk Access doesn’t help. So I’m stuck again.
All problems solved!
We added bash to the Full Disk Access list in the systems integrity panel – problems with file access gone!
I did add launchd and sh there before (since sh is used by Applescript) – but not bash.
So bash seems to be the owner of the processes when IDS is started by LauncAgents.
I have a AppleScripts that use ‘at’ command and the only way for me to make that work was to include ‘at’ to have full disk access.
Also I need to
com.apple.atrun.plist are disable as default. After the change in the plist
It will work.
Maybe its a similar to your problem…
It sure was. I guess Apple don’t want to make it too easy for users to allow disk access to such hidden processes without knowing what they are and might do - in contrast to applications with a GUI, whose disk access the user will be asked for - as with the Terminal in my case.
Anyway, thanks to a college that was more keen than me to read the system log, everything’s fine for us now.
Why Apple make its difficult is because of security reasons. So other process couldn’t
access your system without your approval. The knowledge I have and that is not much but most times if it matters to a users something else need to be done.
The great thing there is always someone else who had the same problem and find
a solution. So its always possible to find more information and many times not from Apple.