Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
When handling a message, regardless if it’s a command or event, you often want to know who sent the message. Who was the message sender? Not the service, but the actual user who initiated it. If it’s a command then who invoked it. If it’s an event, who invoked the command that changed state within the system that created the event.
This post is in a series related to messaging. The overview is available in my Message Properties post.
The most common reason for wanting to know who sent a message is to determine if they are authorized to perform whatever action is being done by a command. The same can apply for events and event handlers. The task of an event handler may be conditional on who caused the event in the first place.
This can be as simple as including a
SenderID along with your message data. A simple example based on other posts in this series:
SenderID would represent a way for your server to identify who is sending the message. This could be a unique identifier of a user within the system.
Another option is to include an ID Token.
ID Tokens are a similar idea but used mainly in token-based authentication. It provides a more performant way of accessing the user profile and access rights. Basically it’s a cached copy of the user profile that was generated when the user authenticated.
One concern here is if you are persisting messages for any length of time, and processing them later, you need to be aware that the ID Token may have expired and may no longer exist in the cache. ID Tokens generally have a lifetime and your message storage may not.
The benefit is access to authorization information that you may need when processing a message. Is the sender authorized to perform an action?
If you have any other ways you like to keep track of the sender, let me know in the comments or on Twitter.