ajvincent / es-membrane Goto Github PK

In other words, let's use the Membrane constructor and appropriate object graph handlers to protect private members of the Membrane from public access.

Bonus: dogfooding!

• Hide private members of Membrane, ObjectGraphHandler instances
• Assert that a ProxyMapping object is never returned from the Membrane
• Freeze Membrane.prototype, ObjectGraphHandler.prototype, any graph handler set via ObjectGraphHandler.prototype.replaceProxy()
• Ensure inherited graph handlers cannot override the fieldName property
• Ensure graph handlers coming into replaceProxy() were first generated inside the Membrane before customization (that they're not proxies themselves)
• Ensure graph handlers cannot use Object.setPrototypeOf() to override the prototype chain after they are passed into .replaceProxy()
• Ensure no value returned from the Dogfood Membrane is wrapped in a Dogfood Membrane object graph, and then wrapped again in another Membrane object graph.
• Tests for all "XXX" comments

Same as issue 11, but with a blacklist instead of a whitelist.

ObjectGraphHandler.prototype.getWrappable(value) should usually return [false, value] for a primitive, or [true, value] for a non-primitive.

membrane.modifyRules(fieldName, proxy, getWrappable) replaces this method with getWrappable.

Major pieces:

• Transforming a primitive into another primitive
• Transforming a primitive into an object, so the Membrane can store references to it
• Tracking method calls across parallel object graphs of the stored primitive, so we can get the impact of the changes in one graph from the other
• Membrane-aware code to set up the initial conversion

The tests for "allowLocalProperties" specifically allow the act of deleting properties to cross the membrane. Because it's unclear whether hiding is better or worse than actually deleting, I claim it's a separate use case.

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

The current build system is probably not the best way for writing Node- and browser-friendly JavaScript code, and doesn't factor in import and export statements for ECMAScript 6. The build system therefore should be reviewed by a Node package authoring expert.

Required for #5.

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

Probably dependent on #6.
Required for #5.

If the "wet" object graph explicitly prevents Foo.prototype.hiddenPropName from being exposed, then it should be possible in the "dry" object graph to do the following:

var x = new DryFoo();
x.hiddenPropName = "notSoHidden";
expect(x.hiddenPropName).toBe("notSoHidden");

var X = getWet(x);
expect(X.hiddenPropName).not.toBe("notSoHidden");

The Membrane code also needs an API to specify how this sort of change would be implemented.

I'm just digging into the library now and noticed https://github.com/ajvincent/es7-membrane/blob/master/source/Membrane.js#L343. Is it possible to also wrap non-configurable and non-writable proxies in the object graph? I am interested in keeping a perfect mirror between the wet and dry spaces.

Here is the example I'm working on:

const dryWetMB = new Membrane({});

// 3. Establish "wet" ObjectGraphHandler.
const wetHandler = dryWetMB.getHandlerByField("wet", true);

// 4. Establish "dry" ObjectGraphHandler.
const dryHandler = dryWetMB.getHandlerByField("dry", true);

// 5. Establish "wet" view of an object.
// 6. Get a "dry" view of the same object.

const wrappedWindow = dryWetMB.convertArgumentToProxy(
    wetHandler,
    dryHandler,
    window,
  );
}

console.log(wrappedWindow.caches);

Examples:

• Logging proxy calls or testing that they ran in the correct order
• Changing environment settings before and after a proxy runs
• Preconditions, postconditions, aspect-oriented programming
• Argument validation for external callers only
• Comparing outputs of different implementations

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

This allows one proxy to alter the results of another in controlled conditions.

Node, CommonJS and browserify are all nice to have, but this is really supposed to be an ECMAScript-friendly module in all respects. That means import and export statements, hopefully without breaking existing browsers and Node targets...

• The field name must be non-configurable, non-writable.
• Inherited handlers should not be able to override the name.

Required for #5.

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

Hey @ajvincent, great work on this project, it's fantastic! I would love to use this project in my other work and contribute. Is there any chance you could add a license to the repo?

This will be necessary for the DogfoodMembrane, which will otherwise leak memory through holding onto revoke functions for unnecessarily generated proxies.

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

This will probably be via use of sandboxes. The goal is to modify the Membrane API so that it can create sandboxes and prepopulate them with appropriately shielded values.

• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

Note that truly hiding an Error's stack cannot begin until the Error enters an object graph handler. If you are in a "dry" object graph and "dry" code calls:

throw new Error("foo");

then the stack cannot be hidden at that line of code unless the Error constructor itself was overridden somehow.

membrane.modifyRules.disableTraps(fieldName, proxy, trapList);

Satisfies #26, #27.

This means a "dry" object graph may have properties which the "wet" graph's objects never see.

ProxyMapping.prototype already has flags effectively for "allowLocalProperties" and "mustDeleteLocally". It will soon need flags for .preventExtensions, .setPrototypeOf.

Similarly, we will want methods:
ProxyMapping.prototype.getLocalFlag(fieldName, flagName);
ObjectGraphHandler.prototype.getLocalFlag(proxyMapping, flagName, recursePrototypes);

We could have three object graphs:

• "internal" for the actual code running
• "public" for the general case
• "debug" for running debug code
• Jasmine specification (disabled) demonstrating the use case
• Implement object graph handlers to achieve the use case
• Enable test for browser target
• Enable test for node target

Thou shalt not bless thine software with the holy "1.0" version number unless another competent developer can verify thine code is reasonable and does what the project says it should.

Suppose the "dry" graph can only influence the "damp" graph, and the "damp" graph is the route to influencing the "wet" graph.

The current implementation has each graph interacting with the original graphs of each object.

membrane.modifyRules.replaceProxy(p, h);
Object.setPrototypeOf(h, someOtherObject);

Required for #5.

ObjectGraphHandler.prototype.fixOwnProperties explicitly defines properties, but this is probably bad. It would be better to cache the list of "known keys" on the ProxyMapping so that we don't require certain properties be defined (particularly since defining properties can sometimes be done only once, per proxy constraints).

If a Membrane object leaks out, there are several ways a bad actor could cause problems:

Membrane.prototype.preventModifications() should be defined to prevent:

• Creating a new ObjectGraphHandler
• Calling convertArgumentToProxy with an override

The dogfood membrane can prevent some things:

• Accessing the map, handlerStack, handlersByFieldName or modifyRules properties
• Calling private methods.

Required for #5. Probably dependent on #6.