Update, based on feedback from the OP:
- The OP's issue is not the use of
property
statements that normally cause an AppleScript-based application to self-modify the application bundle's embeddedContents/Resources/Scripts/main.scpt
script file when property values change at runtime. - However, Apple's workaround at http://support.apple.com/kb/HT5914
- IS specifically meant to address not requiring re-authorization as a result of this self-modification issue for a given version of an application.
- is NOT meant to allow updating the app (changing its source code or resources) without re-authorization.
For security reasons there is NO way to grant one-time authorization to an app based on its bundle ID and then keep it authorized no matter how it changes (e.g., through updates).
You have two options:
- Either: Re-authorize the application every time you update it.
- After updating your app, go to
System Preferences > Security & Privacy > Privacy > Accessibility
and toggle the checkmark next to the list item representing your application (if you application isn't there, drag it there). - Note: With Apple's workaround in place - which for security reasons is NOT a good idea unless you truly need to use
property
statements that persist their values - it may be sufficient to re-sign the application - haven't verified that.
- After updating your app, go to
- Or: Use a workaround - not recommended for security reasons:
- Make your app an unchanging wrapper that loads the true script code at runtime from a location OUTSIDE the app bundle - that way, the app stays the same and doesn't require re-authorization even if the script file loaded at runtime changes.
- Example: Say your true script code - involving code requiring assistive access - is stored as
~/Desktop.test.scpt
; your wrapper application, once authorized, can then invoke that script withrun script file ((path to home folder as text) & "Desktop:test.scpt")
I don't have a specific explanation, but a recommendation:
Do not use properties (e.g.,
property FNAME : "Input.txt"
) in your AppleScript-based applications: AppleScript persists these automatically (preserves their values between runs), but the feature is implemented awkwardly (the persisted values are written to the*.scpt
file itself - this is what causes the repeated authorization problem) and flimsily (if you modify your application and save (the*.scpt
file at the heart of the) application again, previously persistent values are lost).If you stay away from properties, the problem with repeated authorization simply goes away (unless you update your application). You can roll your own persistence, e.g., via AppleScript's support for
.plist
(property-list) files (see theSystem Events
dictionary).- You also won't need the workaround described in the linked support article (http://support.apple.com/kb/HT5914), which is also a plus, given that the workaround is based on opening up a security hole.
As for your specific question:
The
??
is the - unhelpful - representation of thecsreq
columnn value from theTCC.db
database and is not a problem per se; OSX manages that column behind the scenes; it contains a fingerprint of sorts identifying the application in its specific current form (similar to an MD5 hash, though I have no idea what is actually being used), so as to be able to detect tampering later.However, I suspect you may be looking at the wrong database entry:
I'm puzzled by your bundle ID being
com.atonus.open-cubase
: if your app is an AppleScript-based*.app
bundle, its bundle ID would have the fixed prefixcom.apple.ScriptEditor.id.
, e.g.,com.apple.ScriptEditor.id.open-cubase
. Did you manually modify the bundle ID via the bundle'sInfo.plist
file, or am I missing something?When the OS determines tampering/a change in an authorized application:
- It resets the
allowed
column value to0
, i.e., revokes authorization - It resets the
csreq
column value toNULL
.
- It resets the
Thus, after you've seen the
... is not allowed assistive access
dialog, the database entry should be reported askTCCServiceAccessibility|com.atonus.open-cubase|0|0|1|
- note the changed Boolean flags and the absence of the??
at the end.