ARTEMIS-6057 support literalMatchMarkers in security repo such that f…

[gtully]

…qqn with wildcards can be supported

[gtully]

@jbertram should I consider combining the exact and literal match maps?

[jbertram]

Couple of things:

• Instead of adding support for literal matches it may be simpler to modify HierarchicalObjectRepository#addMatch to check both wildcard and FQQN. The benefit is that users wouldn't have to configure literal matches (and incur the performance penalty) and it makes sense anyway to treat a wildcard + FQQN as an exact match.

if (literal) {
   literalMatches.put(modifiedMatch, match1);
} else if (wildcardConfiguration.isWild(modifiedMatch) && !CompositeAddress.isFullyQualified(modifiedMatch)) {
   wildcardMatches.put(modifiedMatch, match1);
} else {
   exactMatches.put(modifiedMatch, match1);
}

• There should at least be one more test to ensure the negative case (i.e., that a user can't consume from or send to the FQQN).
• There's some weird white-space that will no longer be allowed since 747c6ce was merged today.
• It would be nice if the commit message was a bit shorter to more closely conform to general recommendation.

[gtully]

thanks for the feedback, that is a simpler approach which will work. Have reworked the fix. thanks

[brusdev]

I'm not sure it is a real use case, however modifying HierarchicalObjectRepository#addMatch to check both wildcard and FQQN would prevent wildcard matches for FQQNs.

[gtully]

I'm not sure it is a real use case, however modifying HierarchicalObjectRepository#addMatch to check both wildcard and FQQN would prevent wildcard matches for FQQNs.

we can revisit that if ever the security check w.r.t FQQN needs to change, at the moment it only checks an exact match.

[brusdev]

we can revisit that if ever the security check w.r.t FQQN needs to change, at the moment it only checks an exact match.

As I mentioned, I'm not aware of any real use case, so I'm not against this change. However, revisiting it in the future could cause backward compatibility issues.