Message Broker / Queue - Wolverine vs. EasyNetQ vs. MassTransit
I currently utilize RabbitMQ with EasyNetQ sitting on top of it ... been using it for years.
Our C#/WPF enterprise app has around 200-300 concurrent users and I am in the process of rebuilding it from .NET 4.8 now in .NET 9.0.
One thing I have noticed is that EasyNetQ does not seem to be receiving any updates and figured it might be a good time to revisit if that is the best fit.
We primarily use RabbitMQ/EasyNetQ to handle "commands" from the client on the server (create/update/delete entities and to execute certain logic on demand).
I am considering either Wolverine or MassTransit ... have not used either before.
Looking for recommendations from folks with deep experience in either framework.
Thanks!!
-Apoc
57 Replies
What is "the client"?
WPF/C# app
It is generally, in my view, not a great idea to directly access the message queue from a client app like that.
Especially with MT or a system similar to it.
I basically use RabbitMQ/EasyNetQ as a request/response service.
Curious as to why you don’t recommend using it like this?
security
MT is the system I have the most experience with. But the assumption is that MT creates the queues it needs. And thus has permission to do so.
Could you elaborate?
I am using Azure Entra authentication… which passes the token in a header in every message.
The token is validated and cached on the server… with sliding expiration.
I am using SSL between client/server with RabbitMQ
Granting all the clients capability to create entities is a security concern.
Ahhh… I see your concern.
I have that handled via security checks in the UI and on the server side.
Well security checks in the UI are completely useless.
I can just open up a management interface, or powershell, or whatever, and access it.
Yes and no.
A normal user cannot even get to say the inventory screen if they don’t have access.
If this is rabbit I can literally just code up a bit of JS to connect to the broker and add/delete your entities.
You’d have to authenticate as a user that has those permissions.
The server side will block you if you don’t have the permissions
You mean the user the UI uses?
I'll just grab that from the UI.
And the token?
If the UI has it I have it.
The UI doesn’t have it.
Then how does the UI connec tto Rabbit?
Whatever the UI uses to connect to the broker I can just steal from the UI and use.
It’s in memory… and encrypted
Yeah that takes seconds to steal.
So what’s your recommendation?
Untrusted clients should communicate over an API that does not allow management access.
Generally HTTP.
MT is not meant to be used on untrusted clients. And if those other libraries work the same,, either are they.
Theoretically I could script HTTP to do the same thing
No, you couldn't.
Because you never wrote an operation to delete/add/etc queues.
So how do you recommend the client (WPF) send a request to the server to delete/add/etc?
Why would the client be deleting or adding queues?
(it wouldn't so you wouldn't)
They aren’t adding/deleting queues.
They are publishing messages to queues that already exist
If they aren't adding or deleting queues then why are you asking how they would add or delete queues?
I never asked that
>So how do you recommend the client (WPF) send a request to the server to delete/add/etc?
I meant delete/add/etc an entity… or perform some action
Same way every other app on the planet does it: by sending an HTTP API request of some kind? =/
Then I can use a script to do malicious things via the HTTP API request… same as with RabbitMQ
Neither one is inherently more secure
No you can't....
This makes no sense.
You are the author of HTTP endpoints.
THe user can only do things you write an HTTP endpoint to let them do.
I am the author of the RabbitMQ queues also.
And I can do more than that.
I can delete them.
That's the difference.
No you cannot
Sure I can. I just send a request to delete them.
The user account I am using doesn’t allow deleting queues
Then it won't work with MT.
Because MT requires manage permission on broker entities. Like I said at the start of this.
Okay… now we are getting somewhere.
>MT is the system I have the most experience with. But the assumption is that MT creates the queues it needs. And thus has permission to do so.
We started somewhere.
Then we went in a big circle.
LMAO
MT will not work unless it has permissions to manage broker entities: that means create queues, exchanges, topics and delete the same.
Because that is the point of the library: to manage those entities for you.
Hence it is not a good plan to run it on an untrusted client.
The server side allows creating queues and managing them.
The client side can only publish messages.
At least that is how my current setup works.
That's not allowed with MT.
Well shit
The entire point of MT is to create the queues/topics/exchanges for you. That is it's bread and butter.
Appreciate your patience on this
You declare .NET classes, you decorate them with interfaces, and a relationship hierarchy, and it automatically manages the queues/topics/subscriptions to allow pub/sub in conformance with that class hierarchy.
How are people dealing with this obvious security flaw?
By not accessing brokers from untrusted clients.
I should note there are still security concerns with RabbitMQ with untrusted clients, regardless of MT. It is incredibly easy to DoS your service if I can submit any message I want.
Very true. The app is internal though… on our infrastructure.
If that happens… we have bigger issues though.
Anyways, apps like this are generally designed so that the broker, the "service bus" is a bus between services, on the server.
For multiple server-side apps to communicate amongst each other.
The clients are untrusted, and communicate with the services through an explicit API, like HTTP.
For real time receipt, streams, and all that sorta stuff, web sockets.
Same reason you wouldn't grant your client app direct access to your SQL database, you wouldn't grant them direct access to your broker.
The client app has direct access to the SQL database.
Readonly … using Entity Framework… read only access.
No permissions to update anything.
Yikes.
Well, you already have my thoughts on that.
lol yep
I used to be concerned about that
back in like 2007.
Maybe I’m getting too old
Doubt it. As I've gotten older, and dealt with more poor designs, I've become stricter.