You can check out the evalInSandbox page on developer.mozilla.org when it's back up.
The point of evalInSandbox is not the modified scope, but the fact that you can eval the code with a web page's privileges. So (I believe so, have not tested) even if you add a variable holding a reference to Components.classes to the sandbox, the sandboxed code still won't be able to instantiate XPCOM components. Nickolay On 7/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Vladimir--you should thank Nickolay because he pointed me to that solution some time in the past. Nickolay--does evalInSandbox() scope the created objects non-globally? Does it ignore CC and CI calls? I've heard your comment before, I'm just curious what makes it safer than eval(). (I'm not questioning you, I'm only trying to learn why it's safer) ----- Original Message ---- From: Nickolay Ponomarev <[EMAIL PROTECTED]> To: Mozdev Project Owners List <[email protected]> Sent: Saturday, July 15, 2006 7:54:56 AM Subject: Re: [Project_owners] Storing configuration On 7/15/06, Vladimír Marek <[EMAIL PROTECTED]> wrote: > Hi Eric, > > > You can use Object.toSource() to serialize the source to a string. To > > read the string back into objects, use eval(string); > > That's excellent, exactly what I was looking for ! :) > Not that it matters much in the case of reading from the preferences, but evalInSandbox is safer/better generally, because a simple eval() executes the code with the chrome privileges, so if the attacker can make you eval() his string, he gains full control over the system. Nickolay
_______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
