consider adding "current caller context" function

[Brian Warner]

This function would allow a remote_foo() method to learn the tubid of the client which sent the activating message. (another possibility is to add magic argument markers to the schema, which would be filled in with locally-generated values that didn't come from the remote client). The "current caller context" function would work by crawling the stack upwards until the foolscap dispatch routine was located, then looking inside that routine's stack frame for the client tubid. It would only be callable from the first reactor turn: if remote_foo() defers execution to a subsequent turn, the information would be lost. This function could also indicate which RemoteReference the message arrived on (in case the same object is referenced in multiple ways).

It's not clear to me that this would be a good idea, but it's occurred to me more than once, so it needed to be written down.

[davidsarah]

What would this be used for? It's a common request in capability systems to want to know the caller identity in order to perform security checks, but that's an anti-pattern, because it interferes with delegation and reintroduces problems with identity-based security that cap systems otherwise solve.