[
https://issues.apache.org/jira/browse/QPID-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432860#comment-15432860
]
Rob Godfrey commented on QPID-7359:
-----------------------------------
{quote}
h4. ConfigurationExtractor
* The handling of encrypted attributes seems odd. Why do we distinguish the
case where an encrypter is present? wouldn't
attributeDefinition.getValue(object) always do the right thing?
{quote}
This is to deal (as best we can) with the possibility of context variables.
{code}attributeDefinition.getValue(object){code} will always get back the value
post interpolation, which isn't what we do with non-encrypted attributes. It
does mean that the case of secure attributes where an encrypter is present
behaves differently as we store the effective value rather than the actual
value - but I didn't see a nice way to get around this.
{quote}
* Similarly, you try to avoid exporting UUIDs when they appear in references
(which makes sense) so isn't saving the obj.getName() always the right thing to
do? Why do we need the if/else?
{quote}
Again, it's trying to preserve the case where a context variable or other
interpolation is used.
{quote}
* Map<> containing COs should be handled specially (i.e. RedirectingVHN) to
avoid exporting UUIDs
{quote}
OK - that's a fair point... I'll add code to deal with keys/values in maps.
Obviously the code isn't going to cope with any deeper or more complex nesting
of structured objects.
{quote}
strange mix of iterator and for-loop in multi-parent handling
{quote}
Yes - the issue is we only want to operate over n-1 entries in the n-element
collection. The code is horrible - but we should just prioritize killing multi
parent objects in the configuration.
{quote}
* VH#extractConfig is only allowed over https. should this depend on
includeSecureAttributes? (btw, Broker#extractConfig has no such restriction.
see my comment on QPID-7380)
{quote}
Conditional security would be nice, but I'm not sure how easy that is to
implement in a generic way. For the moment they should both probably only be
available over TLS. I'll fix this.
{quote}
h4. LegacyAccessControlAdapter
* VH#extractConfig is not mapped to a legacy operation so would always be
allowed (see below)
{quote}
Given the previous mechanism didn't require any special permission, and that
really all this does is retrieve the same data as a normal REST GET operation,
I'm not sure any special permission should really be required ... or rather, we
should look at permissions in a broader scope to make sure that they are
properly defined, however I think I'm comfortable with not requiring any
special permission.
{quote}
h4. Sidenote:
* LegacyAccessControlAdapter#authoriseMethod returns Result.ALLOWED by default.
should it not be DEFER or null or error?
{quote}
This is simply doing what the legacy code did which was if there was no
specific call out for the method for a permission, then it was allowed.
Perhaps it would be better to explicitly list all the "no permission required"
methods and update the legacy adapter every time we add a new one, but that is
probably something we should discuss as part of ACL work
> Improve ability to clone a broker's configuration
> -------------------------------------------------
>
> Key: QPID-7359
> URL: https://issues.apache.org/jira/browse/QPID-7359
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
>
> As a user, I may wish to clone all or part of Broker's configuration, so I
> can source control configuration and create many Brokers with identical
> configuration.
> We already have a REST operation to extract the configuration, but when
> invoked from the Broker it extracts the entire object tree. The user needs
> the ability to extract Broker and Virtualhost configuration separately.
> The existing {{extractInitialConfig}} RestServlet option should be removed
> and in its place operations added at the Broker and Virtualhost level. The
> generated extract should stop at the discontinuities within the model.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
