thron7-2 wrote:
>
>>
>> As mentioned, the qooxdoo way of declaring classes doesn't let one use
>> closure variables over the whole of the class. Currently, the generator
>> removes all code outside of the class definitions when generating the
>> build
>> code.
>
> Hu?! How come? Have you proof of that?
>
>
Actually, I don't - that was the case last time I checked, so it might have
changed, or might have even never been the case! I experienced that when I
tried adding shortcut methods to the dialog contrib namespace manually in
the class files (a bad idea, I know, but just as way of proof). I added to
the source file, after the class declaration some code which did something
like dialog.alert = function(...){...}. This code was not included in the
built code, or at least, that is what I inferred from the fact that it
worked in source mode but not in build mode. So this is what prompted me to
think that all code outside the class declaration was removed during the
"compilation". So if this is not the case, I stand corrected -- should have
done some testing beforehand.
thron7-2 wrote:
>
>> (function(){
>> var foo;
>> qx.Class.define("my.special.class", .{... });
>> })();
>
> That is actually what happens, AFAICT.
>
So you're saying that the current generator wraps all the code contained in
a file in "(function(){...})();" already?
thron7-2 wrote:
>
>> This way, an attacker would have NO way of accessing the closure
>> variable.
>> In contrast, the "private" member properties with the mangled names can
>> be
>> easily accessed by iterating over the object properties.
>
> What is your notion of "attacker" here? Do you have a specific exploit
> scenario in mind?
>
To be sure, the attack scenario comes from the world of mashups which is not
(yet) really relevant in qooxdoo apps: the integration of third-party code
to be included in the javascript execution context, which then goes to
search for sensitive information that is available to it. So this is more a
question of principle rather than one that is currently of practical
relevance. However, I am thinking of qooxdoo apps which allow third-party
plugins to add functionality to its core. Given that the main application
instance is available from anywhere by qx.core.Init.getApplication(), one
can, with enough effort, access every member of every object that is saved
as the member of an object linked in some way to the main application
object. Of course, using loose coupling and local variables instead of
members can avoid that. But the use of closure variables over the whole
class declaration would be an easy way of creating variables that are
accessible to the whole class without being exposed to third party scripts.
Do you see what I mean?
Thanks,
Christian
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5513576.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
