Re: AppleScript & HTML Again
Re: AppleScript & HTML Again
- Subject: Re: AppleScript & HTML Again
- From: Roger Howard <email@hidden>
- Date: Thu, 25 Mar 2004 17:24:47 -0800
With all due respect, and with a nod towards the limitations of Web
browsers as application environments, there are considerable reasons
why browsers are used to access (not host) applications - namely,
about
the only cross-platform, network-based application toolkit.
That's only worthwhile if the application in question needs to run
zero code
on the client, or is 100% pure, tested, cross platform Java.
And much of what I see as interesting (I'm not saying I'd use it in
production, certainly not unless Apple implemented it themselves) is
the use of AppleScript as the backend language for a Web app being
accessed from another machine. I'm not saying there's no other way
around this - one could call osascript from a perl script for instance,
and get much of the same effect - but opening up AS as essentially a
CGI language would just give it one more interface it can be called
from.
If someone wants to write some backend code in AppleScript, and then
provide access to that code to users on a variety of platforms, a
Web-based UI is one of the only (or at least most common) ways. It's
no
replacement for full-fledged desktop applications, but they often
serve
very different purposes. Really, this argument would sound really
silly
if you were advocating a Cocoa UI for Yahoo - Yahoo is best served by
browser-based UIs, even with all of their limitations.
Yahoo is designed from the ground up for web browsers, so of course a
web
browser works as s front end there..
Exactly. For apps that are designed from the ground up as Web apps,
they are appropriate for the browser. You seem to be arguing sweepingly
that AppleScript - a language - shouldn't be able to be used as an
embedded Web scripting language - because the browser is a stinky
environment for apps. But then you acknowledge some apps are
appropriate for display in a browser, but haven't explained why
AppleScript shouldn't at least be able to be used in such a manner.
Sure, AS has its heritage in scripting GUI apps, but it's not
inherently GUI language - most of my scripts have virtually no direct
user interface, much like most Web apps. Instead, I pipe output to
various environments... t'would be interesting to be able to use an
AppleScript compiler as an "app server" and preprocessor for HTML.
Apple once provided use with the ability to use AppleScripts as CGI
scripts... now I'm just suggesting they do the same thing in a slightly
more modern way.
You can also write Java front ends that
will run cross platform. A web browser is only good in a limited set of
circumstances, most of them having to do with state.
I see this as a good addition to AppleScript - like any language, it
can be useful for more than just desktop applications... having
essentially a CGI bridge to AS could be highly useful to some, where a
solution like PHP won't necessarily solve the same problems (without
bridging PHP to AppleEvents at least, or more commonly Python).
The problem comes down to security. How do you use SSL or Kerberos with
AppleScript?
SSL and Kerberos don't define security for Web apps. Many apps (or the
app servers) are secure regardless of whether they use SSL for
encryption or Kerberos for authentication. If you don't need Kerberos
auth and you don't need to encrypt your data across the network, then
the security issues are primarily whether there are frontend holes in
the script interface, and whether its possible to commit remote
exploits like buffer overflows (in other words, force the system to do
something the system admin doesn't intend). In this regard I don't see
how the concept of AS as a CGI language is any less secure than PHP, or
perl, etc. Most sites I visit that are dynamically served don't use SSL
and most don't require any form of authentication (save the news
sites).
As others have pointed out, the security question is (or may be) a red
herring... as long as measures are taken to provide for
authentication,
as long as the scripts are run at the right user level, as long as
there are safeguards to prevent arbitrary injection of code from
non-authenticated users, how is this any more dangerous, different, or
even scary as having PHP, perl, etc, on the same box.. every one of
those tools could potentially do malicious things, and as always its
up
to implementors (and the original developers to some extent) to help
make sure that doesn't happen.
Because I can use the security in Apache, and tools like SSL, Kerberos,
cgiwrap and suexec, and a host of other tested security
implementations that
don't exist in AppleScript. I'm unaware of Kerberized AppleScript, or
SSL-Aware AppleScript. How do you link authentication in an AppleScript
application to a KDC, or Active Directory setup? How do you use
personal
certs to ensure that only those folks who are authorized can get to the
data?
Security is ALWAYS a concern in a networked enviroment.
I never said it wasn't. Security is a function of understanding the
needs of a given application, and in securing the backend from remote
exploitation. SSL doesn't make something inherently secure. And
Kerberos is unnecessary for many Web apps. That doesn't make things
insecure. If there was an exploit where arbitrary code could be
remotely inserted onto the system and executed with elevated privelges,
that would be insecure. But conceptually I don't see why this is any
more likely with AS/CGI as it would be for any other scripting
language. Hell, perl wasn't designed as a language for dynamic site
serving, but it did a good job of it for a long time before the
Web-specific languages took over.
-R
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.