include slot (usually boardID) in label of synthetic remotables
for example: [object Alleged: Brand#board0123] instead of just [object Alleged: Brand]
Security Considerations
Some similar things can only be done for debugging because otherwise they divulge info to parties that shouldn't have it.
But I believe it's OK in this context even in production: the client already knows the boardID.
Scaling Considerations
n/a
Documentation Considerations
I expect this to enhance clarity in some situations. (I hope to contribute something similar to the vstorage viewer.)
I don't consider these labels to be part of the API, so I do not consider this a breaking change.
I'm not aware of any clients that depend on the string form of these labels. Feedback from reviewers on this is particularly welcome, in any case.
Testing Considerations
one straightforward unit test is included. seems sufficient for such a small change
This does add @endo/init to devDependencies of rcp to use @endo/marshal in the test.
Description
include slot (usually boardID) in label of synthetic remotables
for example:
[object Alleged: Brand#board0123]
instead of just[object Alleged: Brand]
Security Considerations
Some similar things can only be done for debugging because otherwise they divulge info to parties that shouldn't have it. But I believe it's OK in this context even in production: the client already knows the boardID.
Scaling Considerations
n/a
Documentation Considerations
I expect this to enhance clarity in some situations. (I hope to contribute something similar to the vstorage viewer.)
I don't consider these labels to be part of the API, so I do not consider this a breaking change. I'm not aware of any clients that depend on the string form of these labels. Feedback from reviewers on this is particularly welcome, in any case.
Testing Considerations
one straightforward unit test is included. seems sufficient for such a small change
This does add
@endo/init
to devDependencies of rcp to use@endo/marshal
in the test.