This feature adds an Access Control Layer on the SDK.
There is an abstract AccessController that needs an implementation in the proper context; for which I created one for WordPress on the plugin. It has a check on a Capability which is also an interface.
The Capability needs to declare whether its mutative (editing, moving, etc) or destructive (deleting). Every Capability is its own class type which defines its own contexts. To aid in the process there is an abstract DataViewCapability which requires a DataView as its context.
In the future extra Capabilities can be added without introducing immediate breaking changes to the Capability or AccessController interface. Adding a Capability class does require all AccessController instances to do a specific check.
This PR also introduces an AccessControlManager which defaults to a ReadOnlyAccessController. This will automatically allow any read capabilities, but reject any mutative and destructive ones.
The manager is a singleton which manages the current AccessController. Meaning the WordPress plugin, for example, will register a specific WordPressAccessController with the SDK. The manager keeps track of any set controllers, and can reset() to the previous one(s).
Anywhere in the code we need to check for capabilities, we need to call AccessControllManager::current() which will return the latest set AccessController. Then we can check the capability there with its context.
This feature adds an Access Control Layer on the SDK.
There is an abstract
AccessControllerthat needs an implementation in the proper context; for which I created one for WordPress on the plugin. It has a check on aCapabilitywhich is also an interface.The
Capabilityneeds to declare whether its mutative (editing, moving, etc) or destructive (deleting). Every Capability is its own class type which defines its own contexts. To aid in the process there is an abstractDataViewCapabilitywhich requires aDataViewas its context.In the future extra Capabilities can be added without introducing immediate breaking changes to the
CapabilityorAccessControllerinterface. Adding aCapabilityclass does require allAccessControllerinstances to do a specific check.This PR also introduces an
AccessControlManagerwhich defaults to aReadOnlyAccessController. This will automatically allow any read capabilities, but reject any mutative and destructive ones.The manager is a singleton which manages the current
AccessController. Meaning the WordPress plugin, for example, will register a specificWordPressAccessControllerwith the SDK. The manager keeps track of any set controllers, and canreset()to the previous one(s).Anywhere in the code we need to check for capabilities, we need to call
AccessControllManager::current()which will return the latest setAccessController. Then we can check the capability there with its context.