Le 17/06/2011 16:35, Tom Van Cutsem a écrit : > 2011/6/16 David Bruant <[email protected] > <mailto:[email protected]>> > > I think I see also a potential security issue. In Tom's code, > getters and setters of the non-configurable properties trigger > code of what was in the handler. This is useful as a user to keep > triggering the get and set traps, but it also leaks a reference to > these functions (after a call to Object.getOwnPropertyDescriptor). > In the current proposal, before a property becomes > non-configurable, there is no access to any trap (unless having > access to the object which implies having indirect access to all > traps or the handler itself). After becoming a non-configurable > accessor property, the get and set trap applied to the > non-configurable properties become available as independant > functions that can be passed around. > Currently, one can revoke the access to an object with a > membrane/wrapper, but with the leak, I think that all > getter/setters will have to be wrapped as well (their call trap in > particular)? Ok, maybe there is no security issue, but it adds a > little bit more work. > > > I don't think there is a potential "leak" in the case of membranes: > the non-configurable property's get/set traps forward to > handler.get/set, which, if |handler| refers to a revoked proxy, will > throw and not penetrate the membrane, as expected. Yep, you're perfectly right. My mistake. It still does leak for the non-membrane case though, but that's a smaller problem, I think.
David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
