activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1890) # any-word wildcard doesn't match zero words if not used at the end of a wildcard expression
Date Thu, 31 May 2018 08:38:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496267#comment-16496267
] 

ASF GitHub Bot commented on ARTEMIS-1890:
-----------------------------------------

Github user jostbg commented on the issue:

    https://github.com/apache/activemq-artemis/pull/2113
  
    @clebertsuconic We are using Artemis as a fast event/message bus for AMQP communication
between (micro-)services developed and operated by different organizational units.
    Each service has it's own LDAP managed login credentials. We allow all services with LDAP
Ids below certain organizational units (base DNs) to access the broker.
    Thus we do not manually grant access to the broker on a per-service/per-application basis.
    
    The functional requirement we are faced with is that a service shall be able to send multicast
messages while maintaining control over which other services are able to read those messages.
    Since there is no finite set of services that are accessing the broker and services shall
be able to specify adressees on a per-message base we cannot work with pre-configured ACL-secured
addresses/queues. 
    
    In ActiveMQ 5.x we could maybe setup something involving a `MessageAuthorizationPolicy.isAllowedToConsume`
but this feature is [not yet available](https://issues.apache.org/jira/browse/ARTEMIS-1884)
in Artemis.
    
    So we came up with a system that involves topic based wildcard routing, auto-created addresses/queues
and a custom Artemis plugin that performs ACLs checks on address/queue access.
    
    It works as follows: 
    A service is allowed to send multicast messages to other services by publishing to addresses
following the naming convention `topics.<someTopicName>.for.<serviceId1>.<serviceId2>...`
where `serviceId1`, `serviceId2` etc are the LDAP authenticated usernames of the services
that are allowed to read the message. 
    Each service that can access the broker has the right to subscribe to addresses following
the naming convention `topics.<someTopicName>.for.#.<myAuthenticatedUsername>.#`
to receive messages addressed to it where `myAuthenticatedUsername` is it's own LDAP id.
    
    This means, if a `serviceA` wants to send information about a newly created contract to
`serviceB` and `serviceC` it publishes a message to the address `topics.contracts.for.serviceB.serviceC`.
`serviceB` subscribes to `topics.contracts.for.#.serviceB.#` to receive all contracts related
messages addressed to it. If `serviceB` then wants to send invoice information to `serviceA`
and `serviceB` it would publishes a message to `topics.invoices.for.serviceA.serviceC`.
    
    The only missing piece for us atm is that `#` must always be interpreted as `zero-or-more`
words as stated in the documentation otherwise services will not be able to receive messages
in all cases.
    
    For performance/resources reasons and simplicity of scaling/operations/maintenance we
do not want to introduce another more sophisticated external routing component like camel
as the setup I described fulfills our requirements.



> # any-word wildcard doesn't match zero words if not used at the end of a wildcard expression
> --------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1890
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1890
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 2.6.0
>            Reporter: Johan Stenberg
>            Priority: Major
>         Attachments: Artemis1890_AnyWordWildCard_Test.java
>
>
> [https://activemq.apache.org/artemis/docs/latest/wildcard-syntax.html] states that the
{{#}} wildcard character means _"match any sequence of *zero* or more words"_. This however
is only true if the wild card is the last character in a wildcard expression. If any word
comes after the wildcard character then the actual behavior is _"match any sequence of *one*
or more words"_
> This means, the pattern {{topics.#.FOO}} matches {{topics.abc.FOO}} but not {{topics.FOO}}
> I am attaching a test case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message