2011/6/16 David Bruant <[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. > I was first enthousiastic by the general idea of keeping get/set traps > through getter/setters (came up first with the fix trap, I think), but since > there is an API allowing to extract these functions independently, I'm not > really sure it's a good idea (in general) anymore. > > David >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
