[Pythonmac-SIG] appscript terminology caching #2

[Ronald Oussoren]

On 23-okt-04, at 12:23, has wrote:

> Ronald Oussoren wrote:
>
>>>>> There's all sorts of issues with starting daemons (like: will the
>>>>> daemon be system-wide or per-user?
>>>>
>>>> It's a user-level process, so I guess that makes it per-user. Out 
>>>> of interest, does [Mac]Python run anything at any other level?
>>>
>>> No, what I meant was "if user Jack starts ATS, then user Has logs in 
>>> (either via the net or with fast user switching), will he use Jack's 
>>> ATS?". Because that could have security implications (such as 
>>> allowing access to terminology for apps to which Jack has access but 
>>> Has not).
>>>
>>> But it turns out this is probably not a problem: as ATS uses OSA any 
>>> problem will exist with AppleScript without ATS too.
>>
>> Depending on how ATS works there could be other problem: there is no 
>> reason to assume that user Jack started a real ATS. What if he 
>> started a modified version of ATS that returns garbage?
>
> Then appscript will fail. But this would be true for any scriptable 
> application. You can only use Remote Apple Events when both client and 
> server can be completely trusted, otherwise it's a massive security 
> hole.

Fail in what way? Could this be used to compromise another account? If 
you send pickles from ATS to the application a fake ATS could execute 
arbitrary code in the application.

>
>
>> What happens when two users are logged on at the same time (Fast User 
>> Switching)?
>
> Don't know how FUS works, so hoping somebody else can tell me how 
> application scripting, RAE, etc. work under it. It's a question that 
> definitely needs answered.

I'd hope that application scripting works in the context of one user 
session.

>
>
>> I don't like a hidden daemon, especially when it accesses the network 
>> and can be accessed across the network.
>
> ATS only operates across the network when an ATS client such as 
> appscript asks it to, and provides it with IP address, username and 
> password for the remote machine in question. And ATS can only be 
> accessed from the network when the machine it's running on has RAE 
> enabled and the other party has valid access permissions. It has no 
> independent network access priviledges - it's merely a gopher for 
> priviledged third parties.

Ah, I hadn't noticed that ATS is only accessed using OSA. I assumed 
that you communicated using some private protocol.
>
>> What about writing the cache in ~/Library/Python/appscript.cache?
>
> Because nobody's yet managed to come up with a solution for a 
> file-based cache that didn't require lots of manual maintenance work 
> by the user, which completely defeats the point of something like 
> appscript whose whole raison-d'etre is ease of use. :)

Most schemes that work for ATS should also work for a manual cache.

>
>
>> Or why use a cache at all?
>
> 1. As a useful performance enhancer that gives us a fighting chance at 
> matching AppleScript for application scripting speed.
>
> 2. As an essential source of terminology data for remote application 
> scripting (as Apple's APIs do not currently support retrieving 
> terminology from a remote machine).
>
> ATS takes care of both tasks with a minimum of fuss and complexity and 
> requires near-zero user interaction, which is why I'm currently 
> preferring it to a file-based cache.
>
>
>> I agree with Bob: if you want the extra performance you can 
>> explicitly create a cache module.
>
> Except this creates extra maintenance hassles for the user, and we're 
> back to having inferior application scripting support compared to 
> AppleScript. Which simply isn't good enough: either we kick 
> AppleScript's butt or else we're just wasting our time, because nobody 
> is going to use a second-rate technology. That's the problem we gotta 
> solve, and it's a bit bigger than simply finding 'something that 
> works'. But then, isn't that half the fun o' programming anyway? ;)

py2app (or a gui wrapper around it) could automaticly perform the 
maintenance hassles: You write a script that uses appscript, drop it on 
"Build Py2Applet" and this scans your script for calls to 
appscript.Application("iTunes.app") (or whatever the call is) and adds 
the relevant terminoligies(sp?) to the .app bundle.

>
>
> Many thanks,
>
> has
>
>
> p.s. Here's an idea for an interesting side project if somebody was 
> interested in pursuing it: an XML-RPC/Apple event bridge. (I read it 
> off some Lisp guy's blog entries while googling for RAE info so can't 
> claim originality, but they were dated 2003 so I guess he never 
> pursued it himself.) Something that hooks a Python-based XML-RPC 
> server to aem, allowing any language that speaks XML-RPC to control 
> applications, and, unlike Remote Apple Events, is designed 
> specifically for use in untrusted environments.

regarding "untrusted environments": only when you add explicit checks 
for security. If the server bridges to all of Apple events you wouldn't 
get a more secure solution.

Ronald