SOLUTION: Anyone here still trying to run applescript from CGI?

[Andre Garzia]

Hello Folks,

every once in a while, people here ask about "How to run applescript  
from CGI", this is specially cumbersome since we're locked with the  
Darwin engine which has no alternateLanguages support. I know that  
me, Kee, Mark Smith and Gary Thompson were looking for such solution  
for some time. I finally was able to do it. It is not straight  
forward and it requires compiling C stuff and the like... but it  
works very fine once it's done.

For the purpose of this email, I'll first talk about how it works and  
then explain on how to implement it.

~~~~~~~~~~~~~~~~~
THE WAY IT WORKS
~~~~~~~~~~~~~~~~~

1) Browser requests a Revolution CGI.
2) Revolution CGI does its stuff and output a file with the  
applescript to be executed.
3) Revolution CGI executes the file using shell() and the following  
command "osascript <filename>"
4) Revolution CGI picks the result from shell() and uses it.
5) Revolution CGI respond to browser.

osascript is a command line tool that executes applescript from the  
terminal. It comes bundled with Mac OS X and it is very nice. So what  
is the problem?! Well the Apache Server is running as user www in Mac  
OS X in a separate universe from the rest of Mac OS X, osascript  
needs to access the windowserver to run (windowserver is the shiny  
thing), the user www can't access such part of the system so calling  
osascript from cgi fails unless we're able to execute osascript as  
another user such as the user that is logged in the machine.

I think that everyone trying to use applescript from CGI is trying to  
query or control some running application, this application is  
running as the logged user, so osascript needs to run like that user.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THE HARD PATH TO APPLESCRIPT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To execute osascript as another user we need Apache suEXEC which is  
an apache gizmo that does just that, execute apps as another user so  
we can make cgis and ssi run as some other guy instead of www. The  
problem is, having a generic suEXEC would be a security breach, so  
you set its configuration during compile time locking it to some  
folders and permissions so that for example, no one is able to run  
your suEXEC as ROOT and hack your machine. To compile suEXEC you need  
to fetch the source for all the apache server and build it, yes, you  
need to compile the whole apache server just to fetch that little  
suEXEC binary from it and put it onto your bundled-with apache. The  
whole compilation of apache on my macbook takes like 1 minute and a  
half, no thats not too painful.

First check what is your apache version with:

httpd -v

then go to apache project homepage and fetch the source to that same  
version. put it somewhere safe and decompress it. Configure apache  
for suEXEC with the following big one line command.

./configure --enable-suexec --suexec-caller=www --suexec-docroot=/ 
Users  --suexec-userdir=Sites --suexec-gidmin=20 --suexec-logfile=/ 
var/log/httpd/suEXEC_log

This will configure apache telling it to enable suEXEC and the  
following things:
	* it will tell that the user that runs apache is www (default on mac  
os x)
	* it will set the root folder for suEXEC to /Users (I'll explain why  
that later, but it is to run as a diferent user)
	* it will set the default folder to "Sites" (Remember that Sites  
folder in you home folder, so we will need that later)
	* it sets a logfile and a GID.

after executing that command to configure apache, you need to build  
it, you do that by doing:

make

You know you need Apple Developer Tools for all this to work for you  
need gcc & friends for building any unix stuff, so if you're trying  
to compile something and you can't chances are that you don't have  
the Developer tools installed, go to apple developer site and fetch  
it, its a 1gb download to XCode, GCC, D-Trace and all the nice C  
things we pray everynight to stay away from us.

After doing the "make" you'll have all the binaries you need. Apache  
will detect the presence of "suEXEC" if it is placed on /usr/bin so  
you just need:

sudo cp src/support/suexec /usr/sbin/
sudo chmod u+s /usr/sbin/suexec

remeber that this path is relative to the apache path. You need to be  
the super user to copy that file to that place, then you set the  
permissions to suEXEC. If this is done right you just need to restart  
apache and check the log file

sudo apachectl stop
sudo apachectl start
cat /var/log/httpd/error_log

you'll see a line like:

[Thu Mar 29 21:21:53 2007] [notice] suEXEC mechanism enabled  
(wrapper: /usr/sbin/suexec)

if everything worked. So now you got suEXEC running on your Apache  
Server... now what... you still need to tell the cgi to run osascript  
as some other guy. See you're usually trying to query some  
application that is running as some user account, the easiest way to  
run suEXEC is to place the cgi on that users "Sites" folder, this  
way, it will run as that user and be able to use applescript with  
anything that that user could do. Thats why we configured suEXEC with  
"/Users" and "Sites".

Putting the CGI on that place alone will not work, you still need to  
tell apache configuration that that specific "Sites" folder for that  
specific user is allowed to run cgi. To do that you go to /private/ 
etc/httpd/users/ and find your user file inside it will be something  
like username.conf. In that file you change the "Options" to allow  
CGI execution and you use "addHandler" to bind an extension such  
as .cgi to cgi execution, you need to restart apache so that the  
configuration changes start working. Mine looks like this:

<Directory "/Users/soapdog/Sites/">
         AddHandler cgi-script .cgi
     Options Indexes MultiViews ExecCGI
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>

this final configuration could probably be done using ".htaccess"  
files too. After this, you can place cgis in the "Sites" folder and  
make them call "osascript filename" that things should work as  
expected. So again a summary:

Step 1) Fetch apache source
Step 2) Compile it with the correct suEXEC params.
Step 3) Move the suEXEC binary to the correct location and set perms.
Step 4) Change user configuration to allow CGI execution from home  
"Sites" folder.
Step 5) restart apache.

It's easier done than explained...

so, the old problem of running applescript from cgi is solved. If  
anyone wants to know, solving this thing took me five big glasses of  
tangerine juice, two sandwiches, one chocolate (while I was  
frustraded that osascript didn't work with www) and three medidation  
showers (yes, I think about code while in the shower, it helps).

cheers
andre