Bill- Thank you for the detailed and thoughtful response. I have done some further poking about and found instructions on granting accessibility permissions from the command line. After doing this on my working app, the AppleScripts no longer execute (error -2709), leading me to conclude that the only way to do what I want is to have the users activate universal access for assistive devices.
To clarify, my app is trying to execute AppleScripts, not receive scripting. I am going to post a follow-up to accessibility-dev to see if there is a way around this. For now, it seems that an application that has been granted AXMakeProcessTrusted cannot access the scripting dictionaries of other applications. Thanks again. > From: Bill Cheeseman <b...@cheeseman.name> > Subject: Re: Using NSAppleScript With AXMakeProcessTrusted -- and/or, > How To Indirectly Launch A Secure Agent > To: Cocoa-Dev Mail <cocoa-dev@lists.apple.com> > Message-ID: <c5aaeb5d.79854%b...@cheeseman.name> > Content-Type: text/plain; charset="ISO-8859-1" > > on 2009-01-31 4:44 PM, Tobias Zimmerman at automa...@gmail.com wrote: > >> So, I have read up on the AXMakeProcessTrusted function, and seen the >> example at http://caffeinatedcocoa.com/blog/?p=12 on how to use this >> function. The problem is, using that approach causes the AppleScripts in my >> application to fail with the error �2709 (can�t access dictionary). > > I can't answer your AppleScript question because I haven't yet made my > scriptable app trusted. But I can comment from personal experience on > AXMakeProcessTrusted because I have it working in the next version of my > PreFab UI Brower product, which is not itself scriptable (I have not yet > released the next version). > > The example code at caffeinatedcocoa.com for the TrustMe application is OK > as an example of how to call the AXMakeProcessTrusted function, but you > shouldn't write a real application that runs as root the way TrustMe does. > It isn't secure to leave an application running as root, and running as root > may be what is killing your scriptability. > > Instead, follow the Apple Authorization Services examples and documentation: > Place a very simple helper application in your main application's bundle. > The only job of the helper application should be to run AXMakeProcessTrusted > against your main application executable. Your helper application has to run > as root for a brief moment because AXMakeProcessTrusted requires root > access, but then the helper application should quit. You might also find > that your main application's scripting interface starts working once it > isn't running as root. > > You can write your main application's executable so that it runs the helper > application at launch time automatically, or as I do you can run it from a > menu item or a button when the user chooses to make the main application > trusted. > >> First question: I have seen a message saying that AXMakeProcessTrusted was >> broken in Tiger. Was it fixed in Leopard? It seems to work correctly, save >> causing my AppleScripts to fail. > > AXMakeProcessTrusted works perfectly well in Leopard. > > I have long suspected that the comments about its being broken in Tiger were > based on misunderstandings about the right way to use it, but I haven't > actually tried to make it work on Tiger so I'm not sure. > >> Next question: Are the AppleScripts failing because the application process >> has elevated rights due to AXMakeProcessTrusted, or is it because the >> application links to the Security Framework? I have seen posts/messages >> that suggest both. If I can get my application the status of >> AXProcessIsTrusted without linking to the Security Framework, will the >> AppleScripts work? (And is this a bug or a security feature?) > > I think I might have read somewhere that scriptability is disabled in an > application that is running as root, for security reasons. If that is > correct, then you should be able to solve your AppleScript problem by moving > AXMakeProcessTrusted into a separate helper application as described above. > Since you should move AXMakeProcessTrusted into a separate helper > application anyway for security reasons, you will be able to answer your > AppleScript question yourself. > >> Third question: Assuming the answers to the first two questions are >> favorable, how would you more experienced and wise developers go about doing >> something like this? How can I do a one-time operation as root without >> linking the Security Framework into my main application? It seems to me I >> need to include two separate agents in my app � one that is run with normal >> permissions from the main app (thus, no need to link to the Security >> Framework or give the main app generally elevated permissions), and then a >> second one, called from the first agent with privileges, that actually >> executes the AXMakeProcessTrusted function on the main app. Does this seem >> right? I am a novice programmer, but I have looked at both NSTask and the >> NSWorkspace - launchedApplication: method and can�t discern the easier way >> to go in terms of passing the main app�s path to the first, and then the >> second agent applications. I am not even sure of the proper build settings >> for a project using two helpers in this manner. Could I use a shell/perl >> script as the middle agent? > > I don't think you need a second "agent" for this purpose. I'm pretty sure > linking to the Security Framework is not your problem. Just put > AXMakeProcessTrusted in a very simple helper application that runs as root. > Then put all the rest of your functionality in your main application's > executable, which is trusted but does not run as root. My main application > puts up the authentication dialog, then it uses NSTask to launch the > AXMakeProcessTrusted helper application and communicates the authorization > ref to it. Apple's authorization example code shows how to communicate the > authorization ref from your main application which puts up the authorization > dialog, to the helper application which runs as root. > > There is one complication that can be resolved by a second "agent": you must > quit and relaunch the main application executable immediately after making > it trusted. The main executable doesn't actually run as trusted until it is > relaunched after AXMakeProcessTrusted is run against it, as the > documentation states somewhere. An easy way to relaunch the main application > executable is to include a second helper application in your main > application's bundle. Example code for doing this can be found at > <http://0xced.blogspot.com/2006/06/relaunch-your-cocoa-application-by.html>. > >> Sorry for the longwinded/semi-ranging question(s), but any and all advice >> the more experienced can offer would be really really appreciated. > > You're in pretty deep territory here, but you've made good progress. Search > Apple's accessibility-dev mailing list archives for more information. > > -- > > Bill Cheeseman - b...@cheeseman.name > Quechee Software, Quechee, Vermont, USA > www.quecheesoftware.com > > PreFab Software - www.prefabsoftware.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
