Problem
The Flowable client reads its upstream credentials straight out of the persisted ApiConfiguration: FlowableClientLocator pulls username / password / token from getConfigJson() when it builds the client. There is no extension point in between, so an application using this bundle has no way to keep the secret out of its database — the seed command has to write it there for the client to find it.
That matters because configJson is served by the ApiConfiguration read API. Even after that read is restricted to ROLE_ADMIN (dmstr/api-configuration-bundle#8), the secret still sits in the database in cleartext, is carried in every dump and backup, and is one serializer change away from being exposed again. A credential that is never persisted cannot leak this way.
Precedent in the same stack
Two sibling integrations in mlr/za7-fogu-api already solve exactly this, and both do it the same way: a token-provider resolver sits between the configuration and the client. The configuration holds only the non-secret identity (base URL, auth type, token URL, client id); the secret is read from the environment at call time and never stored. Their seed commands say so explicitly in the docblock, naming the API-readable configJson as the reason.
The Flowable integration cannot follow that pattern today, because the seam lives in application-owned code in those two cases and does not exist here.
Proposal
Introduce a resolver interface the application can implement to supply the credentials for a resolved ApiConfiguration, with the current behaviour (read from configJson) as the default implementation. Concretely:
- an interface along the lines of
FlowableCredentialProviderInterface, resolved per request from the configuration
- default implementation keeps reading
configJson, so nothing changes for existing installations
- applications that want the stronger guarantee register their own implementation and stop seeding the secret
The shape of the seam matters more than the naming: it has to sit where the client is built from the configuration, so that a configJson without any credential fields is a valid, working configuration.
Why this is filed here rather than worked around
The consuming application deliberately does not patch vendor behaviour or override the resource metadata locally — the fix belongs at the root. Until this exists, that application accepts a weaker guarantee for Flowable than for its other two integrations, and documents the difference rather than presenting them as equivalent.
Context
Filed with AI assistance (Claude Code).
Problem
The Flowable client reads its upstream credentials straight out of the persisted
ApiConfiguration:FlowableClientLocatorpullsusername/password/tokenfromgetConfigJson()when it builds the client. There is no extension point in between, so an application using this bundle has no way to keep the secret out of its database — the seed command has to write it there for the client to find it.That matters because
configJsonis served by theApiConfigurationread API. Even after that read is restricted toROLE_ADMIN(dmstr/api-configuration-bundle#8), the secret still sits in the database in cleartext, is carried in every dump and backup, and is one serializer change away from being exposed again. A credential that is never persisted cannot leak this way.Precedent in the same stack
Two sibling integrations in
mlr/za7-fogu-apialready solve exactly this, and both do it the same way: a token-provider resolver sits between the configuration and the client. The configuration holds only the non-secret identity (base URL, auth type, token URL, client id); the secret is read from the environment at call time and never stored. Their seed commands say so explicitly in the docblock, naming the API-readableconfigJsonas the reason.The Flowable integration cannot follow that pattern today, because the seam lives in application-owned code in those two cases and does not exist here.
Proposal
Introduce a resolver interface the application can implement to supply the credentials for a resolved
ApiConfiguration, with the current behaviour (read fromconfigJson) as the default implementation. Concretely:FlowableCredentialProviderInterface, resolved per request from the configurationconfigJson, so nothing changes for existing installationsThe shape of the seam matters more than the naming: it has to sit where the client is built from the configuration, so that a
configJsonwithout any credential fields is a valid, working configuration.Why this is filed here rather than worked around
The consuming application deliberately does not patch vendor behaviour or override the resource metadata locally — the fix belongs at the root. Until this exists, that application accepts a weaker guarantee for Flowable than for its other two integrations, and documents the difference rather than presenting them as equivalent.
Context
ApiConfigurationunder/adminis readable by anyROLE_USER—configJsonexposes upstream credentials api-configuration-bundle#8 — restricting the read and redacting credentials on the way out; complementary, not a substitute: it narrows who can read the value, this issue removes the valuemlr/za7-fogu-apiissue #106Filed with AI assistance (Claude Code).