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
