Re: [qooxdoo-devel] Scalable Javascript Architecture
You're right, they are static. Thanks for pointing this out. Which is not a
problem when dealing with really unique data such as password,
authentication tokens, etc., but might be undesirable in other use cases.
I don't know to answer your question, that's a tricky one. Maybe one could
use an object as a closure variable and use the object hash code of the
instance as an index into this object:
var mySecretVar = {};
qx.Class.define("my.classUsingAClosureVar",
{
...
someMemberFunc : function()
{
var mySecretInstanceVar = mySecretVar[this.toHashCode()];
...
}
...
});
Certainly not pretty, and all the instances can access each other's secret
variables, which is also not what we want. It is just not the same as doing
var MyClass = (function(){
var mySecretVar;
return {
someMethod : function()
{
doSomethingWith(mySecretVar);
}
)
}());
Cheers,
Christian
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5518484.html
Sent from the qooxdoo mailing list archive at Nabble.com.
--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Scalable Javascript Architecture
On 09/09/10 23:46, panyasan wrote:
> Which, to close the issue, means that you can define variables outside the
> class definition, as use them inside the qooxdoo class as super-safe data
> containers. This might be worth mentioning in the docs. They won't be
> documented in the API viewer, but that's part of the idea. Doug Crockford
> suggests to save session, password or other sensitive data vulnerable to XSS
> attacks in such variables.
i'd like to point out that such variables are private static variables,
and not private instance variables. so they're orthogonal to what
qooxdoo offers with its double-underscore prefixed variables.
you can "emulate" private instance vars with closure vars. but first
some background:
in case you need to replicate C++ templates-like functionality in
languages that support closures, like javascript and python, you can do
this:
def get_application(template_argument):
# a class that does something with the template argument
class Application(object):
def get_template_argument(self):
return template_argument
return Application
this will instantiate a new class definition every time its parent
function is called, which is not unlike how C++ compilers implement
templates.
doing this in qooxdoo is a little problematic though:
var get_application = function(template_argument) {
// a class that does something with the template argument
return qx.Class.define('test.Application', {extend: qx.Core.Object
,members: {
get_template_argument: function() {
return template_argument
}
}
}
}
here, how do we name the class? i don't know the answer to that. it'd be
nice to agree on a canonical way to do that though.
so, if you want to treat closure variables like private instance
variables, you need to instantiate a class definition for each class
instance. which is not possible with qooxdoo classes due to the above
reason.
but for use-cases like holding session identifiers, private statics will
certainly do the job. i agree with christian that this would do a nice
addition to the documentation.
best regards
burak
--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Scalable Javascript Architecture
So I finally did some testing. The following "source" code:
var closureVar = "Hello world of closures!" ;
qx.Class.define("test.Application",
{
extend : qx.application.Standalone,
members :
{
main : function()
{
this.base(arguments);
var button1 = new qx.ui.form.Button("First Button", "test/test.png");
var doc = this.getRoot();
doc.add(button1, {left: 100, top: 50});
button1.addListener("execute", function(e) {
alert(closureVar);
});
}
}
});
is transformed to the following "build " code:
(function(){var g="Hello world of closures!",f="test/test.png",d="First
Button",c="execute",b="test.Application";
var a=g;
qx.Class.define(b,{extend:qx.application.Standalone,members:{main:function(){qx.application.Standalone.prototype.main.call(this);
{};
var i=new qx.ui.form.Button(d,f);
var h=this.getRoot();
h.add(i,{left:100,top:50});
i.addListener(c,function(e){alert(a);
});
}}});
})();
As Thomas said, no code is removed and the class code is wrapped with a
function. So my assumptions were incorrect. Sorry about not doing more
reseach before posting!
Which, to close the issue, means that you can define variables outside the
class definition, as use them inside the qooxdoo class as super-safe data
containers. This might be worth mentioning in the docs. They won't be
documented in the API viewer, but that's part of the idea. Doug Crockford
suggests to save session, password or other sensitive data vulnerable to XSS
attacks in such variables.
Cheers,
Christian
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5516074.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
Re: [qooxdoo-devel] Scalable Javascript Architecture
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
Re: [qooxdoo-devel] Scalable Javascript Architecture
Hi, I'm happy that qooxdoo way of doing things is like other GUI libraries. Closures seems to be cool, but are they really useful to library like qooxdoo? Personally I don't see a reason to use them, are privates so important to you that you want to hide them? The convention with two underscores just works, you see easily these members in debugger and generator already obfuscates them. Just my two cents;) Best regards Petr Kobalicek On Sun, Sep 5, 2010 at 11:14 AM, panyasan wrote: > > Hello list, > > a few days ago, I watched a presentation by Nicolas Zakas on "Scalable > Javascript Architecture" in the fantastic "YUI theatre" presentation series > with all the Crockford fun lectures: > > http://developer.yahoo.com/yui/theater/video.php?v=zakas-architecture > http://www.slideshare.net/nzakas/scalable-javascript-application-architecture > > I found the model he is presenting totally convincing (Core, Sandbox, Module > - Architecture) and am currently trying to take over some of the ideas into > a new app I am currently building. However, the technique he is using is > really working with JavaScript the way it was meant to be used (functional > programming with heavy use of closures). In contrast, as everyone knows and > enjoys, qooxdoo is trying to bring a different programming model which is > closer to traditional-style OO. In particular, the use of "private > variables" via closures is hard to emulate with qooxdoo when one wants to > keep using the qooxdoo "classes". In exchange, the generator provides for > "private" variable by way of mangling the variable names of members that > start with double underscore. However, the security this offers is not > comparable to the closure-way of doing things. > > I wonder if some of the ideas presented in the talk could find their way > into qooxdoo. Or is it already there and I just don't know about it yet? > > Thanks, > > Christian > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5500032.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 > -- 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
Re: [qooxdoo-devel] Scalable Javascript Architecture
>
> 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?
> However, if there was a way to keep those variable definitions such
> as:
>
> var foo;
> qx.Class.define("my.special.class", .{... });
>
> we could be using one javascript feature that Doug Crockford has correctly
> identified as THE security mechanism built into javascript. Of course, for
> it not to become a gloval variable, the generator would have to tranform
> the
> code into:
>
> (function(){
> var foo;
> qx.Class.define("my.special.class", .{... });
> })();
That is actually what happens, AFAICT.
> But that wouldn't be too difficult, would it? It wouldn't work in "source"
> mode but source mode is never to be used in production anyways.
>
> 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?
T.
>
> Cheers,
>
> Christian
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5510046.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
>
>
>
--
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
Re: [qooxdoo-devel] Scalable Javascript Architecture
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. However, if there was a way to keep those variable definitions such
as:
var foo;
qx.Class.define("my.special.class", .{... });
we could be using one javascript feature that Doug Crockford has correctly
identified as THE security mechanism built into javascript. Of course, for
it not to become a gloval variable, the generator would have to tranform the
code into:
(function(){
var foo;
qx.Class.define("my.special.class", .{... });
})();
But that wouldn't be too difficult, would it? It wouldn't work in "source"
mode but source mode is never to be used in production anyways.
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.
Cheers,
Christian
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5510046.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
Re: [qooxdoo-devel] Scalable Javascript Architecture
You're welcome. This programming model is really powerful. The more I use it, the more I realize that, in a very natural way, it solves quite a number of problems that I have been struggling with previously ... C. -- View this message in context: http://qooxdoo.678.n2.nabble.com/Scalable-Javascript-Architecture-tp5500032p5503947.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
Re: [qooxdoo-devel] Scalable Javascript Architecture
Hi Christian, thank you for sharing. Our team is this week not completely in office, so please be patient for a answer. Cheers, Chris Am 05.09.2010 11:14, schrieb panyasan: > Hello list, > > a few days ago, I watched a presentation by Nicolas Zakas on "Scalable > Javascript Architecture" in the fantastic "YUI theatre" presentation series > with all the Crockford fun lectures: > > http://developer.yahoo.com/yui/theater/video.php?v=zakas-architecture > http://www.slideshare.net/nzakas/scalable-javascript-application-architecture > > I found the model he is presenting totally convincing (Core, Sandbox, Module > - Architecture) and am currently trying to take over some of the ideas into > a new app I am currently building. However, the technique he is using is > really working with JavaScript the way it was meant to be used (functional > programming with heavy use of closures). In contrast, as everyone knows and > enjoys, qooxdoo is trying to bring a different programming model which is > closer to traditional-style OO. In particular, the use of "private > variables" via closures is hard to emulate with qooxdoo when one wants to > keep using the qooxdoo "classes". In exchange, the generator provides for > "private" variable by way of mangling the variable names of members that > start with double underscore. However, the security this offers is not > comparable to the closure-way of doing things. > > I wonder if some of the ideas presented in the talk could find their way > into qooxdoo. Or is it already there and I just don't know about it yet? > > Thanks, > > Christian -- 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
