Calendar - create new event AppleScript - error type 1743 - Mavericks

I have a script that I used to create a new iCal (now Calendar) event that worked fine in Mountain Lion but does not work in Mavericks.

As far as I understand an error type 1743 means that there is a problem with access. I have allowed my script to “control my computer” in the Accessibility section of the Privacy panel of the “Security & Privacy” pane in System Preferences but I still get this error. When this did not prevent the error I allowed apps from anywhere in the General Panel of the “Security & Privacy” pane but to no avail.

It does appear to be an access problem however because when I open the script with AppleScript Editor and run it from there there is no problem. I have allowed AppleScript Editor to “control my computer”.

I considered that it might be an issue with allowing an “app” to access my calendar in the Calendar section of the Privacy panel of the “Security & Privacy” pane in System Preferences, however firstly I cannot allow my script to access my calendar by dragging the script into this window as I can in the Accessibility section and secondly I have not, and cannot, allow AppleScript Editor to access my calendar.

I have a similar script to create repeating events and I use both all the time (my life sometimes feel like one long meeting). I trigger them with a keyboard shortcut using either FastScripts or Butler and it really feels like I’ve lost an arm (or at least a digit) so would be very grateful if some-one can help solve my problem.


global AppType
global AppSummary
global AppLocation
global AppDate
global AppDuration
global StartTime

set theDate to short date string of (current date)

display dialog "Do you want to create a new diary entry for home or work?" buttons {"Home", "MyWork", "People"} default button "MyWork"
set AppType to button returned of result

display dialog "What's the appointment for?" default answer ""
set AppSummary to text returned of result

display dialog "Where is it?" default answer "Rm W5.09"
set AppLocation to text returned of result

display dialog "For what date?" default answer (theDate as text)
set AppDate to text returned of result

display dialog "For how long?" buttons {"1 Hour", "All Day"} default button "1 Hour"
set AppDuration to button returned of result

if AppDuration = "All Day" then
	set allday to true
	set eStart to date (AppDate)
	set eEnd to date (AppDate)
	
else
	display dialog "Enter begin time:" default answer "09:00"
	
	set StartTime to text returned of the result
	set eStart to date (AppDate & space & StartTime)
	
	
	set AppDuration to 1
	set eEnd to (date (AppDate & space & StartTime)) + (AppDuration * hours)
	set allday to false
	
end if

tell application "Calendar"
	tell calendar AppType
		set newEvent to make new event at end with properties {summary:AppSummary, location:AppLocation, start date:eStart, end date:eEnd, allday event:allday}
		make new mail alarm at end of mail alarms of newEvent with properties {trigger interval:-1440}
		make new mail alarm at end of mail alarms of newEvent with properties {trigger interval:-2880}
	end tell
end tell

Here are some pointers that have helped me solve a v similar issue:

  1. Be sure to trash all duplicates of the app & create a new version in AppleScript Editor 2.6 (Mavericks version):
    The app will then have a unique CFBundleIdentifier in its info.plist – older (Snow Leopard) apps don’t have this entry!!

NB: When you trash all copies of the app, it will no longer show in the System Preferences/Security & Privacy pane – until you create the new version. If you create it with a new name, it will be treated as a new app, and you’ll get the option to allow access on the first run.

  1. Sign the app. IMPORTANT
    info here: http://support.apple.com/kb/HT5914?viewlocale=en_US&locale=en_US
    It seems Applescript applets aren’t remembered unless they are code signed.

  2. As a last resort, reset the accesibility list.
    info here: http://macosxautomation.com/mavericks/guiscripting/reset.html
    This will remove ALL applications from the list, so BEWARE, you’ll have to add them all again!! It’s helped solve issues for particular apps for me.

I must say, I too use a lot of apps, and it’s been a real pain getting them to work smoothly in Mavericks! When I’ve modified an app, I’ve needed to re-sign it and re-add it. Though, sometimes just toggling the checkbox in the Accessibility pane is enough ??? Perhaps someone who understands can shed some light…

Anyway, here’s a utility to simplify signing.
Save as an app and drop ResourceRules-ignoring-Scripts.plist downloaded from the link above into Contents/Resources


--"sign app" v2 Jan 2014

--signs apps in 10.9
--Requires ResourceRules-ignoring-Scripts.plist in Contents/Resources
--Save as app
---------------------------------

set path2prefs to path to preferences
set path2prefs_POSIX to POSIX path of path2prefs
set ResourceRules_name to "ResourceRules-ignoring-Scripts.plist"
set ResourceRules to (path2prefs as text) & ResourceRules_name
set ResourceRules_POSIX to POSIX path of ResourceRules

--main
display dialog "Sign App? " buttons {"Cancel", "Choose App"} default button 2 with icon 1

--verify ResourceRules
tell application "Finder"
	if not (exists ResourceRules) then
		tell me
			activate
			display dialog "The required file \"" & ResourceRules_name & "\" was not found! Do you wish to install a copy in ~/Library/Preferences?" buttons {"Cancel", "Install"} default button 2 with icon 0
		end tell
		
		--install...
		duplicate file (((path to me) as text) & "Contents:Resources:" & ResourceRules_name) to path2prefs
	end if
	
	--choose app
	set theFile to POSIX path of (choose file)
end tell


set myText to "codesign -s - --resource-rules=" & ResourceRules_POSIX & " " & quoted form of theFile

try
	do shell script myText
	activate
	display dialog "Signed. Now please run the App... allow access when asked." buttons {"Done"} default button 1 with icon 1
	
on error the error_message number the error_number
	activate
	display dialog "Error: " & the error_number & ". " & the error_message buttons {"Cancel"} default button 1 with icon 0
end try



From the Apple tech note on code signing:

I would assume that this security vulnerability is low risk for the average person/applescripter, but since nothing else is said about it, how can you be sure? Does anyone know what the vulnerability is, what circumstances might expose this vulnerability to those who wish to exploit it, and what you might do to minimize it?

Dear Dewshi,

that was extremely helpful, thanks. I had been trying to find how to “sign” the apps but had not found anything as concise and clear as in your reply.

I recreated the script in the Mavericks Editor and retested before signing (I wanted to follow through each step and see where the problem fixed) and this actually solved my problem.

I have also downloaded the resource plist file and if my “app” fails again, I’ll know what to try next,

thanks again, (as I said in my first post I really use this a lot and it’s good to be able to use it again)

J

I can confirm that I have this problem too.

I’m basically trapped in this loop

  1. create a new applescript
  2. copy the content from earlier script
  3. name it something different than the earlier script and save it as an application
  4. sign it with dewshi’s nice little app (thanks for that)
  5. run it and give access when prompted
  1. run it again and it works!
  2. …make any change to the script and start from 1. again.

This 7. point is there because OSX keeps prompting

after I make a change to the script and doesn’t go away, even if I grant the access to it in Security & Privacy.

So Mavericks basically crippled my scripting workflow.

I was thinking that maybe you could have a script runner. It has permissions and can run any script.

gl,
kel

But then you can’t launch the apps with different keyboard shortcuts.

I launch several scripts with FastScripts.
I was asked once to allow the app to do its duty and was never asked again.

I have also one script saved as .scpt which I run from the Script Editor.
When it has done its job, it starts an other script saved as an application.
In this case I was also asked only once to allow it to do its duty.
As I’m using my own scripts, I didn’t feel useful to sign them.
Maybe it’s what makes the difference.

Yvan KOENIG (VALLAURIS, France) lundi 26 mai 2014 16:46:09

@atonus

Strange, I don’t have this issue: once an app is signed & allowed access it keeps running fine… I’ve made amendments too by editing the main.scpt in Contents/Resources/Scripts (rather than creating a new app). This seems to work fine. I’m triggering via Quicksilver, though apps work as normal too.

Have you tried nuking the accessibility list as detailed in my previous post?

Hi,
I’ve just upgraded to Mavericks and discovered there was GUI security issue with lots of my AppleScripts.:confused:

If I :
¢ copy/Paste my script in a new document
¢ save with another name
¢ delete the old script so that it disappear in accessibility system preferences
¢ sign the applet, thanks to dewshi’s script :slight_smile:
¢ run the script and give access when prompted
. it works sometimes and sometimes it’s still asking for access (contacts, gui.) :o. Even if I made no changes to the newly created script.

Did someone find a real workaround for making applescript work properly ?

I also tried with Quicksilver executing scripts saved as “.scpt” but it’s much slower than the script saved as an application, is it normal ?

Thanks for your answers !

Will it work better if my Applescripts are saved in Application Folder ?

Dewshi (and others),

Don’t do this any more – it will fail when the applets are run in 10.9.5 and 10.10.

See: developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205

Read the section Changes in OS X 10.9.5 and Yosemite. In particular, it says:

Do not use the --resource-rules flag or ResourceRules.plist. They have been obsoleted and will be rejected.

The easiest way to codesign your apps is to use File → Export in AppleScript Editor, where you will find a popup to select the signature. This will also modify the script so that properties are not written back to it, which is the other thing that can cause repeated prompts.

Does this mean you’ll need a Developer ID certificate to allow your script Accessibility in the Security & Privacy System Prefs… even if you just want to use your script on your own system?

I understand you have to pay an annual subscription for one.

That’s a good question. I was thinking more in terms of Gatekeeper, where you certainly do.

The issue of Apple ID versus other signature is really a separate issue. The question is whether, when version 1 signatures are no longer accepted by Gatekeeper, will they still be accepted for Accessibility? I don’t know the answer, but I’d suspect the move to version 2 signatures would be across the board. But I’m only guessing – they may well have decided to be less strict with Accessibility.

We need someone running one of the betas to try it.

For a Developer ID that works with Gatekeeper, yes. But you can register for the free developer program, and the Mac Developer certificate included with that shows up in the Export dialog in AppleScript Editor.

Hi, thank you for pointing this !

Perhaps that would allow our broken workflows (because of erratic behavior when asking for access) to work better.

Anyways I found a workaround using FastScripts and shortcuts. I saved my Applescripts as “.scpt” rather than the application format.
Quicksilver is executing scripts saved as “.scpt” much slower than Fastscripts, which, on the contrary, seems to speed up my scripts.

FastScripts is very well named.

Registering for the free developer program allows you to use your Developer ID certificate for Safari Extensions only (as far as I can tell??). But you can code sign apps for your own use by creating your own certificate in Keychain Access:

Choose menu Keychain Access/Certificate Assistant/Create a Certificate…
(mine’s named com.dewshi)
Export your applescript as an app, selecting Code Sign:

Naturally this will only work locally, i.e no good for distribution, but allows persistent access via the Security & Privacy System Prefs now that ResourceRules.plist is redundant in 10.10. (Thanks for pointing that out Shane!)

Below is an alternative method, replacing the script in my previous post. I haven’t figured out how to verify the certificate! Surely should be possible with verify-cert command (??), but I can’t get my head around it. If anyone knows how, please let me know.


--"sign app" v3

--Requires certificate!
--(create in Keychain Access, using Certificate Assistant)
---------------------------------

set myCertificate to "<your certificate name>"

--main
display dialog "Sign App? " buttons {"Cancel", "Choose App"} default button 2 with icon 1

--verify certificate???

--choose app
set theFile to POSIX path of (choose file)

--sign app
set myText to "codesign -s " & quoted form of myCertificate & " " & quoted form of theFile
set myText2 to "chmod a-w " & quoted form of (theFile & "Contents/Resources/Scripts/main.scpt") --make read only
try
	do shell script myText
	do shell script myText2
	activate
	display dialog "Signed. Now run the App... allow access when asked." buttons {"Done"} default button 1 with icon 1
on error the error_message number the error_number
	activate
	display dialog "Error: " & the error_number & ". " & the error_message buttons {"Cancel"} default button 1 with icon 0
end try