[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407595#comment-15407595
]
angela commented on OAK-4599:
-
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.7
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407440#comment-15407440
]
angela commented on OAK-4599:
-
[~chetanm], that was the missing piece! confirming that this indeed shows the
issue. to be really sure I added also run a variant the changes the
{{AuthorizableActionProvider}} config _before_ disabling the unary
configuration. Thanks so much for looking into this, very much appreciated.
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405970#comment-15405970
]
angela commented on OAK-4599:
-
[~chetanm], I would appreciate if you could take a look at the very first patch
against {{oak-pojosr}}... maybe you see a compelling reason why we don't manage
to reproduce the issue in an OSGi-based setup?
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599_test_1_2.patch, OAK-4599_test_trunk.patch,
> OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404139#comment-15404139
]
Francesco Mari commented on OAK-4599:
-
I looked at your first two patches and I didn't see anything that I would do
differently. They both look good approaches to me, and it's kind of strange
that they are not able to reproduce this issue. Maybe [~chetanm] can help a bit
more with the patch targeting {{oak-pojosr}}? The third patch, the one with the
refactoring, looks good to me.
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599_test_1_2.patch, OAK-4599_test_trunk.patch,
> OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404130#comment-15404130
]
angela commented on OAK-4599:
-
[~frm], not that i would like that but i really don't see another way to
reproduce the issue in oak. May I kindly ask you to review the proposed
refactoring... once we are good here, I think step 2 is somewhat redundant as
we can't discuss alternative approaches to fixes this if we cannot reproduce
the original issue... so only 3 and 4 would be left.
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599_test_1_2.patch, OAK-4599_test_trunk.patch,
> OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404112#comment-15404112
]
Francesco Mari commented on OAK-4599:
-
[~anchela], I didn't find any better way of writing a test against a full OSGi
deployment. I recognize that testing a very specific section of code buried
under dozens of line of OSGi-related code can be problematic at best, so I
strongly approve the approach of your latest patch. If something is hard to
test precisely, it's way better to factor it out and make it more test-friendly.
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599_test_1_2.patch, OAK-4599_test_trunk.patch,
> OAK-4599_trunk_var2.patch
>
>
> 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 resolved 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)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395369#comment-15395369
]
angela commented on OAK-4599:
-
proposed next steps:
# unit tests illustrating the issue in OSGi setup; to be provided either in
{{oak-core}} using some OSGi-mock or in {{oak-pojosr}}
# discussion of potential alternatives for a fix
# implementing fix in trunk
# backporting tests and fix to brances
> 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.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: 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 resolved 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)
