Skip to content

Add an explanation the need for Context's Restore operation. #490

@carlosalberto

Description

@carlosalberto

From #424 (comment)

  • Checking correctness - by having a restore that accepts a Token or just simply the previous Context you can check if the given value is the expected one (in other words you can see the calls to set as push to a stack and restore as pop where you check that the element you intend to pop is the expected one. This is critical and I've seen cases where auth tokens were leaked because of this issue (I don't think I can share too many things about this issue, but the root cause were people calling set without a paired restore).
  • This approach guarantees (at least tries to enforce because mistakes can still happen) that the Context is not "modified" by calling a function:
void bar() {
  Context current = Context.current();
  foo();
  // This should always be the case, otherwise for examples
  // credentials can be leaked here.
  assert(current == Context.current());
}

It can still happen if a Set is not followed by a Restore, but by having the Restore users can identify very soon this wrong behavior because the next Restore call will give a signal to the users (log, crash, based on a config).

So this API helps users use the Context API in an expected way.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions