[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: kross
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-01-03 21:43:37
Message-ID: 200701032243.38222.mail () dipe ! org
[Download RAW message or body]

Thomas Zander wrote:
> for kross defining of what can and can not be called by a script is by
> making it a QObject and exporting the methods to use as slots.
> 
> I think a clearer method is to use
> 
> Q_SCRIPTABLE
> or
> Q_INVOKABLE
> for marking methods callable by QMetaObject::invokeMethod.
> This is more clean in the API docs IMO.
> 
> Q_INVOKABLE is used to turn any member function (aside from slots and
> signals) into functions invokable by QMetaObject::invokeMethod
> 
> Q_SCRIPTABLE = Q_INVOKABLE + set the scriptable qProperty.
> 
> What do you think?

I started work on this for kjs+kjsembed some time ago + committed already 
working code. The idea was, to don't hard-code such limitations but be able 
to define exactly what slots are published (private, protected, public, 
Q_SCRIPTABLE, read/write properties, etc.) and for the case of kjs+kjsembed 
even a way to prevent calling some of the dirty functionality an evil script 
could use to crash the app (setParent, delayedDestruct, etc.).
But it's not that easy to add such "permissions" and therefore the work done 
so far is still marked as TODO/WorkInProgress and it's easy to escape 
such 'limitations' within a script.
So, my plan was to first add such 'optional limitations' to kjs+kjsembed and 
maybe one day be that way able to run even untrusted scripts comming from 
untrusted sources. And once that's done extend other interpreters to do the 
same. But looks as priority on this is fallen down under in favor of other 
things that showed up lately (priorities are a moving target here). So, long 
text short message: I don't really know :)

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]