Subscription Authorization in v6

[SeanFeldman]

Looking at the difference between v5 and v6 for subscription authorisation, it looks like NSB is adding unnecessary complexity to get the data that could be passed into the func or, alternatively, be available off the context.

To perform authorisation, one has to get the message type, the client endpoint, and the intent. So why not to provide it?

var transport = endpointConfiguration.UseTransport<MsmqTransport>();
transport.SubscriptionAuthorizer((messageType, intent, clientEndpoint, context) =>
    {
        // true to allow false to decline
        return x;
    });

or

var transport = endpointConfiguration.UseTransport<MsmqTransport>();
transport.SubscriptionAuthorizer(context =>
    {
        var subscriptionMessageType = context.SubscriptionMessageType;
        var messageIntent  = context.MessageIntent;
        var endpointName = context.SubscriberEndpointName ;
        // true to allow false to decline
        return x;
    });

[timbussmann]

preferring option2, as we used the same approach on the custom SLR policy.

[timbussmann]

should we give this a maintainer prio since this is a small task which can easily be picked up?

[danielmarbach]

To be honest I don't see much value in this at the moment. Let's postpone for a minor

[timbussmann]

Let's postpone for a minor

how so? by providing both APIs?

[andreasohlund]

Given that message driven pub sub is more becoming a niche thing should we consider closing this?

[timbussmann]

well there are not really any changes done to MDPS so I'd say let's keep it in the backlog for now and revisit your suggestion once we reduced the usage of MDPS?

[SeanFeldman]

"MDPS" as in "Message Driven Pub/Sub". Not even a TLA 😛