angela created OAK-4599:
---------------------------
Summary: SecurityProviderRegistration fails to update config param
of SecurityConfiguration(s)
Key: OAK-4599
URL: https://issues.apache.org/jira/browse/OAK-4599
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.6, 1.4.5, 1.0.32, 1.2.16, 1.1.8
Reporter: angela
h4. Steps to reproduce
- start Oak repository in OSGi setup with additional required (custom) services
that are passed to various security modules as config parameter such as e.g.
{{RestrictionProvider}}, {{UserAuthenticationFactory}},
{{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
- verify that the security setup contains the custom configurations
- now, force a re-registration of the {{SecurityProvider}} by changing a
referenced/required security service, which is not associated with the custom
configuration as specified in the initial setup
- once completed any {{SecurityConfiguration}}, that is associated with custom
configuration params such as the examples listed above will no longer have the
corresponding params set.
h4. Finding step by step
- {{SecurityProviderRegistration}} waits until all configured required service
references have been registered and all non-dynamic references have been
resolved.
- Once everything is resoslved the {{SecurityProviderRegistration}} looks as
expected including all configuration parameters
- {{SecurityProviderRegistration}} now starts creating a new
{{SecurityProvider}} instance with all the unary and required module references.
- During this step it also calls {{initializeConfiguration}} in order to have
the modules populated with additional stuff from the
{{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
{{initializeConfiguration}} will push the params from
{{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at the
same time trying to merge params defined directly on the
{{SecurityConfiguration}}.
h4. Explanation
In a plain Java setup as it was initial designed for the
{{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
need to take precedence over those present in {{SecurityProvider}}.
However, In our new, pure Osgi setup, where there is no such mixed-param-setup,
we would need a mandatory overwrite of e.g. {{RestrictionProvider}}s or
{{AuthorizableActionProvider}}s, because the _old_ values in the
{{SecurityConfiguration}} had not been provided by it's own config but as a
matter of fact refer to the old values of the {{SecurityProviderRegistration}},
which got unregistered and thus are stale service references.
h4. Potential Fixes
In any case we must have a unit-test that illustrates the problem and allows us
to verify that whatever fix we apply actually addresses the problem. I will try
to provide that today.
h5. Variant 1
Looking back my feeling is, that we should have moved all those extra-params
that get pushed to the {{SecurityConfiguration}} as references to the modules.
Not sure if/how that is feasible at the current state without risking too many
compatibility issues and regressions.
h5. Variant 2
Since we no longer have a mixed java/osgi setup since the introduction of the
{{SecurityProviderRegistration}} and removed the OSGi-annotations from the old
(now pure java) {{SecurityProviderImpl}}, we might consider just changing the
following call in {{SecurityProviderRegistration}} from:
{code}base.setParameters(ConfigurationParameters.of(parameters,
base.getParameters()));{code}
to
{code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
parameters));{code}
and thus actually doing what we intend to do: replace the existing entries in
the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
