Every storage collection a plugin uses has to be a declared manifest resource (undeclared fields are dropped on write), and declared resources are then exposed through the host's generic plugin-resource CRUD to anyone holding plugins.read / plugins.configure. There is no private or secret-scoped plugin storage.
Consequence. Any state a plugin keeps is readable and writable by hand through the admin, including state the plugin treats as a credential. In my case that is licence/activation state: an operator can read the stored key and instance secret, or hand-write an "active" record.
To be clear, I am not asking for DRM. No client-side scheme resists the owner of the machine, and I have accepted that: my mitigations are limited to re-checking entitlement on the paths that matter and enforcing expiry locally, so a revocation still lands on the next successful validation. That is honest-customer friction and I am fine with it.
The part that I think is a genuine platform gap is the other use case: API credentials. A plugin that stores a third-party token (an analytics key, an OAuth refresh token) has nowhere to put it that is not browsable by every admin user. Host-encrypted manifest settings exist and are server-read-only, which is great — but they are a fixed form, so they cannot hold per-item or dynamically-created credentials.
Ask: a manifest flag such as resources[].private: true that hides a collection from the generic admin CRUD and makes it readable and writable only by the owning plugin's server runtime.
Use cases: licence/activation state, per-connection API credentials, anything a plugin mints and must later verify.
Every storage collection a plugin uses has to be a declared manifest resource (undeclared fields are dropped on write), and declared resources are then exposed through the host's generic plugin-resource CRUD to anyone holding
plugins.read/plugins.configure. There is no private or secret-scoped plugin storage.Consequence. Any state a plugin keeps is readable and writable by hand through the admin, including state the plugin treats as a credential. In my case that is licence/activation state: an operator can read the stored key and instance secret, or hand-write an "active" record.
To be clear, I am not asking for DRM. No client-side scheme resists the owner of the machine, and I have accepted that: my mitigations are limited to re-checking entitlement on the paths that matter and enforcing expiry locally, so a revocation still lands on the next successful validation. That is honest-customer friction and I am fine with it.
The part that I think is a genuine platform gap is the other use case: API credentials. A plugin that stores a third-party token (an analytics key, an OAuth refresh token) has nowhere to put it that is not browsable by every admin user. Host-encrypted manifest settings exist and are server-read-only, which is great — but they are a fixed form, so they cannot hold per-item or dynamically-created credentials.
Ask: a manifest flag such as
resources[].private: truethat hides a collection from the generic admin CRUD and makes it readable and writable only by the owning plugin's server runtime.Use cases: licence/activation state, per-connection API credentials, anything a plugin mints and must later verify.