Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: Chris Page <email@hidden>
- Date: Tue, 16 Dec 2008 04:36:23 -0800
Just catching up. It took me a while to find the time to respond in
detail.
On Dec 14, 2008, at 2:53 PM, Ed Stockly wrote:
I'm wondering if everyone on the list understands that commands like
these are all part of what is being discouraged here:
tell application "Finder" to set myFileName to name of (choose file)
tell application "Finder"
set myFiles to every file of (choose folder)
set the name of myFile to the text returned of (display dialog
default answer "File Name")
set the name of myFile to date string of (current date)
set myFile to every file of (choose folder) whose modification
date < (current date)
set myCase to ASCII character of character 2 of the name of myFile
end tell
Yes. It's unnecessary and undesirable to put many of those scripting
addition commands inside that tell block.
Placing all those lines inside the tell block confuses things and
makes it more difficult for someone reading the script to know whether
the script is intended to depend upon sending those commands to Finder.
Instead, I would probably write:
tell application "Finder"
set myFileName to name of my (choose file)
set myFiles to every file of my (choose folder)
end tell
set the name of myFile to the text returned of (display dialog
default answer "File Name")
set the name of myFile to date string of (current date)
tell application "Finder" to set myFile to every file of my (choose
folder) whose modification date < my (current date)
set myCase to ASCII character of character 2 of the name of myFile
Now we can see that only three lines actually need to involve Finder,
and none of the scripting addition commands need to be sent to Finder.
Note that you can use "my ..." and "... of me" to send commands to the
script (and ultimately to the application running the script) without
breaking them out into separate lines.
CP>>2. The dialog is modal and prevents the user from interacting
with the target application.
SS>>I'd be sad to see that go.
CP>>Why is that important for your scripts? Is it critical for
correct operation or just nice-to-have? Do you need to be able to
prevent the user from interacting with the target application?
First, remember that we're often scripting multiple applications:
Finder, Filemaker, InDesign and PhotoShop all in one script, heck
maybe even in the same tell block.
In one case I may include all the UI related commands in the Finder,
but that may be an arbitrary decision. I would hope to avoid the
delays required whenever the UI focus is changed, so, if the script
is launched from within InDesign, for example, then all the UI
commands would be sent to InDesign.
Note that whether the dialog is displayed in front of the active
application is a separate issue from whether the dialog is displayed
within the application, preventing user interaction with the active
application.
It is important for me to find out which aspect is important.
And yes, it may be critical that the user doesn't interfere when a
script is running.
But interfere with what, exactly? Is it important for a script running
in process A to prevent users from interacting with process B by
displaying a modal dialog in process B? Note that the script will
pause and process A will typically not allow user interaction while
the script is waiting for process B to respond to the dialog command.
Here's how I'd assume it would be handled. AppleScripts are always
launched from within some application. Either the finder, or an
applications scripts menu or a system process.
Define "launch". When you open an application, that is called
"launching". If you open a script applet, that is "launching". But if
you run a script within an application, that's "running a script". The
key difference is that the script is running inside an existing
process, not creating a new process.
Even if they're sending commands to a process with additional
privileges, they should not have privileges beyond their inherited
privileges without some kind of authorization.
Exactly. Today they do. Scripting commands operate with the privileges
of whatever process is handling the command.
If launched from the finder they should not have permission beyond
what the user has in the finder, and the same should be true for any
application or process.
You cannot run a script within Finder. You can launch/open a script
applet from Finder. But then the applet is running in its own process
and is not subject to Finder's privileges. Every process has its own
rights and privileges. This is the problem with sending certain
commands from one process to another.
If you sent one of these other processes a ‘do shell script’
command it would execute that command using the privileges of that
user instead of yours.
I can see how shell scripting can open a new dimension of
challenges, but the shell scripting mechanism also has ways of
passing a user or administrator password that can allow additional
privileges.
You cannot normally invoke ‘do shell script’ with administrator
privileges without actually supplying the ‘with administrator
privileges’ parameter. But if you send ‘do shell script’ to a process
that has administrator privileges, the ‘do shell script’ command and
the shell commands it invokes all run with administrator privileges.
This is (approximately) the problem that Security Update 2008-005
addressed.
I would really hate to see the entire language munged just to allow
for an additional vulnerability introduced by 'do shell script'
To "allow for" a vulnerability? Just the opposite. The goal is to
eliminate vulnerabilities by preventing scripts from sending unsafe
commands to other processes. They should instead send the commands to
the process that is running the script.
Has [Security Update 2008-005] broken many scripts in the wild?
Some. And in every case so far, the breakage has been due to scripts
placing scripting addition commands inside tell blocks, thereby
sending them to other processes when it was completely unnecessary to
do so.
I don't mean to be disagreeable, but seriously there must be a
better way.
I haven't yet figured out whether we're agreeing or disagreeing. I
don't think you quite understand what I was trying to say.
I would suggest limiting permissions and privileges to whatever the
current user and the current application have, and require
additional authorization to go beyond (either a user password or a
password embedded in the script).
Yes.
And let us keep writing osax commands in tells.
And that is what I was talking about. How to do that? The simplest way
is to always handle scripting addition commands in the process running
the script instead of sending them to the tell target. But this has
compatibility risks. Some commands behave differently depending on the
process they are handled in, and some scripts may rely upon this
(intentionally or incidentally). And there are programs that send
scripting addition Apple Events without using AppleScript.
As for users not knowing if it's the finder that displays a file
dialog or an osax, that's part of the zen of appleScript.
Huh? ‘display alert’ displays a modal dialog. The application that
displays the modal dialog prevents user interaction with that
application until the user dismisses the dialog. Users can easily see
which application is displaying the dialog. The question is, do you as
a script author need to be able to block user interaction with
arbitrary applications that you target, even though they are not the
ones running the script?
We can write scripts that work and not know all the details or even
the basics about how things work, and our scripts work. As we learn
more about scripting those details reveal themselves.
Yes. And languages should be designed to make it easier to write
correct programs and harder to write incorrect programs, especially
programs that are subtly incorrect in a way that's not obvious to
users, especially the less experienced ones. I'd rather the language
minimized how often this happened by requiring the user to be more
explicit about which events are intended to be sent to other
applications.
Tell blocks and scripting additions as they exist today enable and
even partly encourage sloppy scripts with lots of code unnecessarily
within tell blocks, and lots of events unnecessarily being sent to
other processes.
--
Chris Page
The other, other AppleScript Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden